Location of hyper's C API

[seanmonstar]

In providing a C API for hyper(#2265, #2278), a decision is needed on where exactly the code should live: either inside the hyper crate, or as a separate one. As usual, there's some pros and cons for both options, which I'll list out.

A separate crate (hyper-capi)

• The API can be versioned separately. Breaking changes in the Rust API don't necessarily mean that the C API must also break.

Optional part of the hyper crate (hyper::ffi)

• If a module in hyper, we can take advantage of crate-internal details. For example, hyper::Error internally is a wrapper for a Box<ErrorImpl>. In order to expose a hyper_error *, we can just return the already existing box, instead of boxing a second time if the code were in a separate crate.
• We don't need to make "intermediate" public APIs if we wish to add an option to the C API that isn't normally exposed in the Rust API.
• We can more easily tie the version of hyper to the version the C API sees, such as when asking for hyper_version().
• We can keep the same library name for both Rust and C: libhyper. If using a separate crate, we can't name it libhyper (so no -lhyper), but something like libhyper_c.
• This module can be an optional ffi (or capi or similar) feature, so it isn't included by default.

[seanmonstar]

This was done in 618f034