More flexible reactor/executor API

While this seems like something that shouldn't be considered for 1.0 IMHO, it would be good to start discussions about how an API could look like and what requirements different folks have here.

Also while this is kind of related to https://github.com/async-rs/async-std/issues/60, my main point here is about being able to have control over the lifetime of the reactor/executor, allowing to run multiple and about which would be used when/where. See also https://github.com/rustasync/runtime/issues/42 for a similar issue of mine for the `runtime` crate, on which everything that follows is based.

----

Currently the executor and reactor and thread pools are all global and lazily started when they're first needed, and there's no way to e.g. start them earlier, stop them at some point, run multiple separate ones, etc.

This simplifies the implementation a lot at this point (extremely clean and easy to follow code right now!) and is also potentially more performant than passing around state via thread-local-storage (like in e.g. `tokio`).

It however limits the usability at least in two scenarios where I'd like to make use of `async-std`.

Anyway, reasons why this would be useful to have (I'm going to call the reactor/executor/threadpool combination a runtime for the following):

1. Usage in library crates without interfering with any other futures code other library crates or the application might use. This would potentially also go with specific per-thread configuration inside the library crate, for e.g. setting thread priorities of the runtime in a way that is meaningful for what this specific library is doing. (See also https://github.com/rustasync/runtime/issues/8)
2. Similar to the above, but an extension with more requirements: plugins. For plugins you might want to use a runtime internally, but at some point you might want to be able to unload the plugin again. As Rust generally does static linking at this point, each plugin would have its own version of `async-std`/etc included, so unloading a plugin also requires to be able to shut down the runtime at a specific point and to ensure that none of the code of the plugin is running anymore.
3. Error isolation. While this is probably done even better with separate processes, being able to compartmentalize the application into different parts that don't implicitly share any memory with each other could be useful, also for debuggability.

Start by reviewing the executor, reactor, and thread-pool implementation and the related issues linked in the discussion, especially async-std#60 and runtime#42. Done would require an agreed design and requirements for explicitly controlled, isolated runtimes, including their lifetime, shutdown, and support for multiple instances.

Written by the indexing model from the issue text.