fs: support all executors, not just the threadpool

[carllerche]

When using the curent-thread runtime, the tokio_threadpool::blocking()
function is not available, which is currently a requirement for tokio-fs to
to run blocking filesystem operations.

Note that tokio-current-thread cannot implement a function equivalent to
tokio_threadpool::blocking() because futures in this single-threaded
executor are not necessarily Send. That means we cannot start executing
the blocking function on the current thread and move the event loop onto a
new thread.

Blocking filesystem operations therefore must be run on a thread different
from the current one. Still, the solution to this problem is not as easy as
"just" spawning blocking operations onto a different thread.

[ipetkov]

Not strictly pushing for this, but an idea around this is configuring the executor what to do with a blocking call. Then the application can decide if a new thread should be spun up, or if the executor will just get blocked.

From a caller perspective I'd like blocking to just work™ so that code can be a bit more generic in warning the executor of a blocking operation, without forcing callers to use a threadpool

[carllerche]

@ipetkov generic blocking is tracked in #588.

[carllerche]

This done on master!