Add condition support to `lib/thread`.

[ta0kira]

This doesn't need to have the same calling convention as pthread_cond_wait, but the semantics should roughly be this:

1. One or more threads block on the condition.
2. A separate thread triggers the condition.
3. All threads continue.

Since pthread_cond_wait requires the caller to both lock and unlock the mutex, this can be built into the "wait" call in the implementation. This means that the mutex can be entirely encapsulated in the implementation.

[ta0kira]

Actually, the condition needs to expose some mutex logic so that the thread doing the triggering can wait for all of the threads to respond.

[ta0kira]

Some questions that need to be answered:

• Should the caller of wait be allowed/required to lock the mutex explicitly?
• Should the caller of wait be allowed/required to unlock the mutex explicitly?
• Should there be a "should wait" flag built into the condition?

All of these questions have a common theme: Is it a general requirement that there be some sort of state that is checked or updated before/after a wait call?

---

An example use-case:

Data is read by one thread and is processed by others.

• If data is available to a processing thread, it should not block.
• If data becomes available, the read thread should continue the processing threads.
• Processing threads should check for data before and after calling wait, which requires a mutex to prevent a race condition between checking/claiming data and blocking.

Processing thread:

lock mutex

while data not present
  wait condition

take data
unlock mutex
process data

Read thread:

read data
lock mutex
append data
unlock mutex
continue condition

In the processing thread, multiple things happen while the lock is held, in addition to wait.

---

So, it might be useful to have the condition expose mutex logic in addition to wait/continue, then have wrappers for use-cases such as the example above.