Implement optional support for rustls

[brson]

Rustls is a pure-Rust TLS library. Just like today we support either curl or hyper + nativetls, add optional runtime support for hyper + rustls. The openssl dep is one of the most troublesome pieces of native code in Rust. It'll be nice to get rid of it.

This will require adding the dependency to rustup_utils, then modifying rustup_utils::raw::download_file to use hyper + rustls when RUSTUP_USE_RUSTLS environment variable is set. Follow the example of RUSTUP_USE_HYPER.

[RustPowers]

For first, need to fix his API. To use an environment variable to support it seems to me superfluous. When rustls stabilizes, you'll be able to remove openssl dependence in the rustup.

[brson]

I'm doing a bit of work on the API right now to clean it up so each HTTP implementation doesn't have to do deal with writing to file and hashing.

@RustPowers The environment variable is there to test the less mature hyper implementation. I don't expect it to stay around forever.

[brson]

This PR adds code for a 3rd HTTPS backend, and plugs rustls into hyper. Doesn't work yet. Next step is to write code for loading the system root cert store (this might itself be a useful standalone crate).

[inejge]

A brief FYI: I've been working on a PoC cross-platform CA cert loading crate, and the results are promising so far: I can enumerate and dump the system CA stores on macOS and Windows in PEM format, and have the code to distinguish between Unix-like systems (which is needed to get at their CA stores.) I'll need another day or two to get everything in shape for integration with rustup.

[brson]

@inejge omg woo!

[inejge]

PR opened, CA loading works but rustls connections hang after TLS negotiation, when the first user data is sent/received. (No relation to cert loading, it also happens with hardcoded values.) Will try to investigate further.

[brson]

There's a very good chance the read/write code I wrote earlier is wrong since it's never been tested.