runtime: cleanup and add config options

[carllerche]

This patch finishes the cleanup as part of the transition to Tokio 0.2.
A number of changes were made to take advantage of having all Tokio
types in a single crate. Also, fixes using Tokio types from
spawn_blocking.

Many threads, one resource driver

Previously, in the threaded scheduler, a resource driver (mio::Poll /
timer combo) was created per thread. This was more or less fine, except
it required balancing across the available drivers. When using a
resource driver from outside of the thread pool, balancing is
tricky. The change was original done to avoid having a dedicated driver
thread.

Now, instead of creating many resource drivers, a single resource driver
is used. Each scheduler thread will attempt to "lock" the resource
driver before parking on it. If the resource driver is already locked,
the thread uses a condition variable to park. Contention should remain
low as, under load, the scheduler avoids using the drivers.

Add configuration options to enable I/O / time

New configuration options are added to runtime::Builder to allow
enabling I/O and time drivers on a runtime instance basis. This is
useful when wanting to create lightweight runtime instances to execute
compute only tasks.

Bug fixes

The condition variable parker is updated to the same algorithm used in
std. This is motivated by some potential deadlock cases discovered by
loom.

The basic scheduler is fixed to fairly schedule tasks. push_front was
accidentally used instead of push_back.

I/O, time, and spawning now work from within spawn_blocking closures.

Misc cleanup

The threaded scheduler is no longer generic over P :Park. Instead, it
is hard coded to a specific parker. Tests, including loom tests, are
updated to use Runtime directly. This provides greater coverage.

The blocking module is moved back into runtime as all usage is
within runtime itself.

[hawkw]

This was more or less fine, except
it required balancing across the available drivers. When using a
resource driver from outside of the thread pool, balancing is
tricky. The change was original done to avoid having a dedicated driver
thread.

If memory serves, there were at least some cases where having many drivers resulted in a performance advantage for IO-bound programs? Has there been any assessment about the performance impact of this change?

[hawkw]

based on our offline conversation, I think the move from a reactor per thread to a shared reactor is probably good. i had some questions about the code changes.