Fix commit dfe4e77b: check hasWaiters() in Enqueue

[gc00]

We were checking hasWaiters() in MCCondWait, and if no waiters, we set the mutex to NULL, associated with that condition variable. That corrupted the stack. We now check in MCCondEnqueue that if hasWaiters() is true, then the old mutex associated with the condition variable is the same as the new mutex being associated with it.

@maxwellpirtle , Could you confirm that I'm using the correct style in asserting this error when McMini detects it?

The second commit creates a small test program in which one thread calls pthread_cond_wait(cond1, mutex1) and a second thread calls pthread_cond_wait(cond2, mutex2). A third thread sleeps and then calls pthread_cond_broadcast(). POSIX says that we can't have two threads simultaneously waiting on the same condition variable, but associating it with two different mutexes. This triggers the FAIL, but in a previous test.

Separately, we should also add error checking for mutexes: pthread_mutex_lock() should fail if the mutex is already locked. pthread_mutex_unlock() should fail if the thread holding the lock is different from the one unlocking the mutex. This would require adding a threadOwner field to MCMutex, to test for correct unlocking. This is important in calling pthread_cond_wait, to ensure that the thread calling it has previously locked the mutex argument of phtread_cond_wait.