Add threadLock keyword -- locks mutex, evals code, then unlocks

[d-torrance]

We add a threadLock keyword as suggested in #3739 (comment) to help write thread-safe code. For example:

i1 : x = new MutableList;

i2 : y = new MutableList;

i3 : scan(1000, i -> schedule(() -> (x##x = null; threadLock y##y = null)))

i4 : #x

o4 = 180

i5 : #y

o5 = 1000

TODO:

• Add documentation
• Deal with any potential issues (e.g., what happens if we cancel a task that locked the mutex before it unlocks it?)

[mahrud]

This is not good. I think you want pthread_cond_wait or similar.

[d-torrance]

From what I've read, pthread_mutex_trylock is the only way to check if a mutex is locked. pthread_cond_wait blocks until some condition is met, and we don't want to block since we want to check for interrupts.

[mahrud]

I definitely think we need pthread conditions, because you can signal only one or all threads using pthread_cond_signal and pthread_cond_broadcast that an event has changed. This is how tasks are implemented too. e.g. this is how taskResult blocks:

M2/M2/Macaulay2/system/supervisor.cpp

Lines 210 to 215 in 2565455

	lock_guard<pthreadMutex> lock(m_Mutex);
	while(!m_Done && m_KeepRunning)
	{
	pthread_cond_wait(&m_FinishCondition,&m_Mutex.m_Mutex);
	}
	return m_Result;

In fact, I suspect if we change interrupt_handler in main.cpp to also signal the current blocking task, it would interrupt just fine.