v0.1.x: allow overriding blocking behavior

[hawkw]

Motivation

The initial version of tokio-compat's compatibility runtime added in
#1663 doesn't support the calls to tokio_threadpool 0.1's blocking.
This is because (unlike the timer, executor, and reactor), there's no
way to override the global blocking functionality in
tokio-threadpool.

Solution

As discussed here, this branch adds APIs to the v0.1.x version of
tokio-threadpool that allow overriding the behavior used by calls to
blocking. The threadpool crate now exposes blocking::set_default and
blocking::with_default functions, like executor, timer, and
reactor. This will allow tokio-compat to override calls to 0.1's
blocking to use the new tokio 0.2 blocking APIs.

Unlike the similar APIs in executor, timer, and reactor, the hooks
for overriding blocking behaviour are #[doc(hidden)] and have comments
warning against their use outside of tokio-compat. In general, there
probably won't be a compelling reason to override these outside of the
compatibility layer.

Refs: #1722

[jonhoo]

Ah, yes. This is the reason why the 0.2 version doesn't actually move the f anywhere, and instead executes it directly in the in_place function. I wonder if we could do something similar here.. But that may be too large a change to worry about it.