Port into the std::future ecosystem.

[sapphire-arches]

Sorry that this is a bit of a patch bomb, but it's mostly a straightfoward find-and-replace job to convert from futures-0.1 to std::future. I'm not sure it should get merged until the upstream libraries (hyper, futures, etc.) make real point releases rather than alphas, but given the size of the patch I figured getting it out here sooner rather than latter was probably a good idea =). As mentioned in the commit message, I'm also converting all the examples (both binaries and docs) from block_on_all to .await.

[sapphire-arches]

Oh, I forgot to mention it above but this is certainly a breaking change since the futures crate is part of the public API.

[sapphire-arches]

Looks like all the compilers in Appveyor are too old, and this change definitely violates the (implicit?) MSRV policy since it requires 1.39.

[adwhit]

Thanks for the PR! I definitely want to make this change but obviously not until the ecosystem is ready. I need to catch up a bit with tokio/hyper but I assume they will formally migrate to std::future soon after rustc 1.39 is released. Still we can probably make these changes before then and just hold off on the release. I will aim to review this week.

[sapphire-arches]

No rush, I hacked this together over a weekend to shave some personal yaks.

Just to capture some of the thoughts I had during the process before they entirely leak out of my head, a few of the hand-implemented features behave a little bit oddly in the context of .await. .await syntax sort of assumes that once a future returns Async::Ready, polling it more won't do any more useful work. That's not really true of the UploadFuture, so maybe we should turn that into a stream. This blocks rewriting the manual state machines for the low-level TwitterFuture and RawFuture since async blocks and functions return unnameable types -- so we would need to either accept some boxing in UploadFuture or retain those manual implementations. I think this also affects most of the Streams too, since IIRC they also store futures directly. I'm not sure how much any of this matters since essentially none of this is exposed to users of the library and tolerating some uglyness internally for efficiency + better user ergonomics is basically what libraries exist for.

[adwhit]

Thanks so much for doing this, and sorry it has taken me so long to take a look at it. The good news is that the ecosystem has settled down somewhat now so I think we can get this release out quite soon.