Export C headers as Cargo metadata for FFI usage

[sagebind]

I am looking to use the FFI bindings of Quiche as a sort of -sys-style crate within the curl-sys crate. Typically, so-called -sys crates will use the links Cargo field, which does the following:

• Causes Cargo to enforce only one version of a crate to exist in a resulting binary.
• Allows the crate to export variables that can be read by build.rs scripts of dependant crates.

The latter feature is typically used to export things such as header include paths and other information needed when building non-Rust dependencies. As a refresher if you need it, here is the Cargo documentation for this: https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key. Note that a crate isn't actually required to actually link to some external library when using this option, it merely declares that a crate represents a native dependency with the given name. (In this case the "native dependency" is Quiche's own unmangled FFI symbols.)

As-is, this PR allows a dependant crate's build script to read a DEP_QUICHE_INCLUDE environment variable that will point to a directory containing Quiche's exported C header file. This can be used by the crate to build a C dependency which wants to compile against Quiche while still leveraging Cargo for dependency management. I'd like to do exactly this in the curl-sys crate to allow users to build curl using Quiche for HTTP/3 support without needing to do any manual configuration.

The tricky part about this is that Quiche doesn't have a separate FFI or sys crate, but rather the main quiche crate itself exposes FFI symbols when the ffi feature is enabled. This complicates things with this use-case because there's no way to conditionally set the links attribute in your crate based on a feature -- it is an all-or-nothing setting. So the big downside of this PR is that Cargo will prevent multiple versions of Quiche from co-existing in a binary, even if FFI isn't being used at all.

I'm not sure of a better way of doing this however considering the current Quiche crate setup, but I am open to other alternative ideas. If this isn't a use-case you want to support, then we may end up making a fork or wrapper around Quiche just for use within curl-sys, which not as ideal, would be workable.

See also alexcrichton/curl-rust#433 for how we would like to use Quiche from within curl-sys.