feat(maitake): add WaitQueue

[hawkw]

this branch adds a WaitQueue type in maitake::wait. this allows
multiple tasks to wait for an event, and be woken either one at a time
(in FIFO fashion), or all at once.

there are additional APIs we could add here, but this is a good starting
place. there probably should be docs examples but i'm lazy.

[jamesmunns]

Added some high level comments - I admit to not totally grokking how everything works yet, but I'm going to go try and integrate this branch into mnemos now, so I might have more meaningful feedback after that.

[hawkw]

@jamesmunns i think i've addressed most of your review feedback; if you're still working on integrating this in mnemOS, i'd be happy to wait for that, but i have a slight preference for merging this now and addressing any additional issues that come up in a follow-up, if that's okay?

[jamesmunns]

Misc note (can totally be a future PR): It might be nice to be able to modify the lock behavior somehow.

For me, any lock contention is likely to be a programming bug, so .try_lock().unwrap() is likely to make a "louder"/easier to catch case for me.

[jamesmunns]

@jamesmunns i think i've addressed most of your review feedback; if you're still working on integrating this in mnemOS, i'd be happy to wait for that, but i have a slight preference for merging this now and addressing any additional issues that come up in a follow-up, if that's okay?

It's integrated and working, no complaints from use! I'll take a quick scan of the recent changes and r+ it.

[hawkw]

Misc note (can totally be a future PR): It might be nice to be able to modify the lock behavior somehow.

For me, any lock contention is likely to be a programming bug, so .try_lock().unwrap() is likely to make a "louder"/easier to catch case for me.

hmm, this isn't a bad idea, but it might be kind of painful to figure out a good interface for overriding lock behavior...could be worth opening a separate issue for?

[jamesmunns]

Two things I don't grok:

What happens if I call "wake" a bunch with an empty queue?

How come this stores a "wakeup" in the queue, rather than keeping it at the "empty" state?

[hawkw]

it's necessary to store a single wakeup in the queue because a task may be attempting to enqueue itself while wake is called, which would result in a "lost" wake. multiple calls to wake on an empty queue will not store additional wakeups; storing a count of wakeups in the queue seems like a job for a semaphore, which i'd also like to add to maitake.

[jamesmunns]

Overall LGTM! Added one "I don't understand" question, but that's mostly on me, unless you want to update the docs to explain.