This commit deprecates `Future::wait`. Instead of having a trait
function, a wrapper is provided at `future::Blocking`. `Blocking` wraps
a `Future` value and provides thread-blocking operation on it.

The same treatment is applied to `Sink` and `Stream`.

Related: tokio-rs/tokio-rfcs#3.

The `CurrentThread` executor is an event loop that allows the user to
spawn tasks that are guaranteed to run on the current thread.

This is done by extracting the scheduling logic from FuturesUnordered
and moving it to a `scheduler` module that can be used by both
`FuturesUnordered` and `CurrentThread` executor.

This is based on the Tokio reform RFC, but also includes some API
tweaks.

This helps prevent accidentally blocking an executor thread.

This enables customizing executor sleeping strategies.

Currently, it is not possible to run a Tokio reactor and a 
`CurrentThread` executor on the same thread. The executor is
hard coded to use condvars for sleeping and the Tokio reactor
requires calling `epoll_wait` (or equivalent) for blocking the
current thread.

The `Sleep` trait is added to abstract over this sleeping strategy.

Beyond just supporting the Tokio reactor, adding a `Sleep` trait is
useful for integrating any logic that requires hooking into the sleep
strategy (e.g. timers).

`executor::CurrentThread` is then modified to accept a `Sleep` value
that allows specifying a custom sleep strategy.

This commit extracts the `TaskRunner` interface from the `current_thread` module
to a standalone interface and also reexports it from the `executor` module. This
is done with #675 as the primary motivation, namely accommodating crates using
`CurrentThread` on foreign event loops like glib. In this situation Rust (and
associated code) can't request to block (aka with `run_with_sleep`) and as a
result need a nonblocking method (`TaskRunner::poll` here) instead.

The `current_thread` module was then reimplemented in terms of `TaskRunner` to
ensure there's no extra duplication.