The spinner is a simple |/-\ at the current cursor position. For non-terminal
events, the root of the event's wire is also displayed to the right of the
spinner to give some indication of what's causing an unresponsive terminal.
I used the simplest synchronization strategy I could think of: u3_utat.mex_u is
a mutex that serializes access to a terminal's state. The main thread holds it
at all times except when processing events. When a terminal receives a %bee blit
with a non-nul bulb (the event ovum), it releases the mutex to let the spinner
thread do its thing. A %bee with a nul bulb halts the spinner by grabbing the
mutex and refreshing the input line.
Off-thread console writes are directly against the underlying fd to avoid
trashing non-thread-safe libuv state. Given the simple locking pattern, calling
libuv from the spinner thread might be fine, but I didn't feel like auditing
vere to rule out concurrent calls. It worked when I tried it, but... threads.
I didn't look into supporting anything other than the main terminal, so
currently it's the only one that receives %bee blits. In daemon mode, the
spinner is disabled entirely and no additional thread is started.
