The current readiness queue implication has some concurrency bugs. So,
instead of fixing the bug, let's rewrite everything! :)

But more seriously, the current implication has some problems (besides
having bugs):

* It's complicated
* It is not fair when using level-triggered notifications
* It is !Sync

This implication will hopefully resolve the bugs, as well as simplifying
the implementation by reducing all the critical concurrent state for a
given node to a single atomic variable. It also changes the queueing
strategy from a stack to an actual queue based on the 1024cores MPSC
queue. However, this queue is able to reuse the nodes.

The last step in making `Poll` fully `Sync` is to coordinate calls to
`poll`. There can only be one single concurrent call to `poll`.

In order to respect the timeout argument to `poll`, Mutex cannot be used
for coordination. This is due to the lack of a `lock_timeout` function.
Instead, we use a combination of an atomic, a mutex, and a condvar. The
atomic enables a fast path when `Poll` is used on a single thread. In
the event of concurrent calls to `poll`, extra threads block using the
condvar until they are granted access.