wakeup() and wakeup_one() dropped the lock before waking the thread(s).
But if a thread timed out at the same time we are planning to wake it,
and if the thread imediately exited, our attempt to wake() it could crash.

Therefore wakeup() needs to continue holding the lock until after the
wake(). When msleep() times out, before it returns it reacquires the
lock, ensuring it cannot return before a concurrent wakeup() does
its wakes.

Note that in the ordinary wakeup() case (not racing with a timeout),
we are *not* negatively affected by holding the lock while wake()ing
because the waking msleep() does not try to reacquire the lock in the
non-timeout case.

Additionally, we use wake_with() instead of separate set and wake
instructions. Without wake_with() we have the (exceedingly rare)
possibility that merely setting _awake=true causes msleep() to
return, and its caller then decides to exit the thread, the
wake() right after the _awake=true would crash.