Supports non-rustc-built-in target.cfg.dependencies

[csmoe]

Fix #148

[csmoe]

@dzbarsky may I have a review from you?

[dzbarsky]

To be honest I don't understand this PR. It does look like the existing built-in mappings are incomplete, but that seems like it can be handled via fleshing them out rather than needing to compute them on the fly; aren't they immutable?

Then, if you just want to have an extra --cfg defined for your build it feels like that should be doable more directly, why do we need to invoke rustc for that?

It also seems odd to me to specify a --cfg at resolution time; I would expect conceptually that people specify it at build time (though of course in Bazel making it a starlark flag wouldn't help here). To me that suggests that it may not make sense to use this in a Bazel setting, but perhaps you have a use case I'm not imagining that makes it necessary?

[csmoe]

it can be handled via fleshing them out rather than needing to compute them on the fly; aren't they immutable

why do we need to invoke rustc for that

Because we must confirm whether rustc actually activates the flag, we can optimize this by caching the --print=cfg result (as Cargo does), though at least one rustc invocation is always required.
https://github.com/rust-lang/cargo/blob/a595d0da21f228b7fdae64d3d5c0e527ea66bb59/src/cargo/core/compiler/build_context/target_info.rs#L221
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

It also seems odd to me to specify a --cfg at resolution time

People might write code like this, using cfg because sdk_dev can't be a feature—doing so would break the additivity of Cargo features. The downside: if --cfg=sdk_dev is missing at resolution time, hack_tls_cert won't be pulled into the dependency graph.

target.'cfg(sdk_dev)'.dependenices]
hack_tls_cert = { version = "1.0" }