Feature flag for thread pool executor

[MajorBreakfast]

With the futures API having landed in libcore in Rust 1.36 and async/.await possibly landing in 1.38, the futures crate will need to eventually transition from alpha status into something more stable. Not all its parts have the same degree of maturity, though. In order to make the crate stable, the stable parts need to be separated from the unstable parts. This is obviously a long process. As one further small step towards this, I'd like to suggest to make the thread pool optional.

AFAIK the thread pool executor in futures-rs was always intended to serve more as an example of how a multi-threaded executor could work, not as an actual production-grade implementation that people should use. There are other implementations like @withoutboats's juliex and probably others that I've just not read about. Am I up-to-date with this? Is this still the purpose of the thread pool executor? If its purpose is still mainly to serve an example implementation, then I think we should make this clear by assigning it a feature flag and making it a non-default feature.

[najamelan]

Why not replace the futures threadpool impl with juliex? I think it would be nice if the futures library had a good threadpool and that way it's less scattered in different crates? AFAICT juliex has seen a lot of work and it sees much more use than the futures threadpool.

It would still be an "example implementation", but also be the one we can use in actual products.

@withoutboats @cramertj ? I could be motivated to try and PR that if there is consensus.