Make cdylib only build when C API required

[seanmonstar]

There's some problems with compiling hyper as a cdylib (rust-lang/rust#82151), and even without problems, it's extra compilation work if you don't need to build a C library. The goal is to make it so users can opt-in to building a cdylib, instead of it being always on. To that end, we've pushed a bit in the tooling to allow this, and here's the steps that need to be done:

• Open an RFC to allow cargo rustc --crate-type cdylib (Cargo --crate-type CLI Argument rust-lang/rfcs#3180)
• RFC is approved and merged
• Feature is added to cargo (One PR)
• --crate-type cdylib causes errors looking for rlib dependencies rust-lang/cargo#10356
• Remove cdylib from hyper's Cargo.toml manifest
• Tracking Issue for --crate-type flag rust-lang/cargo#10083

[seanmonstar]

It's now possible in nightly to enable this at runtime:

cargo rustc -Z unstable-options --crate-type cdylib

Since the C API is "experimental", perhaps we can require that nightly cargo be used already...

[seanmonstar]

@bagder how do you feel about using "nightly" cargo. If installing Rust with rustup, you can just run rustup install nightly and then run cargo +nightly blah blah (or rustup default nightly to skip needing to add +nightly for a directory).

The background here is that currently hyper sets in its manifest to build both a Rust lib (rlib) and a C lib (cdylib) at the same time. This is wasteful, and causes some problems for people building Rust in some environments. But it's the only "stable" way to specify library type. We've added the ability to cargo to specify this at command-line time, but it will take a while to become part of "stable" cargo. By using this now, we can a) fix some of those other Rust builds, and b) test the nightly feature so it can become stable.

[bagder]

Whatever helps you go about this in a more convenient manner I will adapt to. Using nightly like this sounds totally doable in my end!