Futex

Although parking_lot_core shortcuts to the unix path, thus not using redox_syscall in practice, it should still be rewritten to use libredox. Libredox thus needs APIs for futex support. Suggested APIs:

fn redox_futex32_wait_v1(word: nonnull *const u32, expected: u32, deadline: nullable *const TimeSpec) -> RawResult;
fn redox_futex32_wake_v1(word: nonnull *const u32, num_wake: u32) -> RawResult;
fn redox_futex32_cmp_requeue(word1: nonnull *const u32, val1: u32, num_wake: u32, word2: nonnull *const u32, max_requeue: u32) -> RawResult;

The reason to suffix both of these with "32", is because it might be useful to implement address or value masking in the future, and because a hash table could be more efficient the more address bits are available due to alignment.

However, Linux's futex syscall has several limitations, such as only being able to wait on one value, and being limited to 32 bits, which explains futex_v2. It might also be useful to implement futexes in userspace, similar to parking_lot_core itself, using an underlying semi-atomic hash table (e.g. lock-free unless shrinking), and a futex-like "wait for thread" rather than "wait for address" syscall.