Ad-hoc: custom metadata for rustc drivers

[jyn514]

I put a brief description in #8 (comment); here's a more complete version.

Some tools want to encode metadata between crates. For example, rustdoc wants to encode aggregated search JSON info, and Ferrocene wants to encode "can this function panic?". Right now, they're either forced to smuggle it through a separate metadata file (in the case of Rustdoc, --parts-out-dir), or fork the compiler altogether (in the case of Ferrocene, add additional metadata to CodegenFnAttrs).

It would be nice to embed this directly into .rmeta files, reusing rustc and cargo's existing support for it.

Constraints:

• Rustdoc won't be able to read Ferrocene's metadata, nor vice versa. We need to add more version metadata so they don't crash when loading the file.
• We do want Rustdoc et. al. to be able to keep reading Rustc's metadata, we don't want to compile the world.

We can solve this by adding a new driver: Option<Symbol> field to CrateHeader. If it's None, any driver can load it, including rustc. If it's Some, only the driver that wrote the metadata file can load it.

Unresolved questions:

• How does cargo caching work in this new world? We had floated the idea of rustdoc emitting .rmeta data, does that still work?
• What type should be serialized? @bjorn3 proposes a new Erased<Lazy> type that is downcast during deserialization, to allow more flexibility for the driver.

cc @epage @bjorn3 @camelid rust-lang/rust#152902 (comment) #69