Platform-specific-ness is carried via deps

[illicitonion]

If e.g. an optional feature is only enabled on certain platforms,
meaning a transitive dependency is only enabled on certain platforms,
currently that information can't be worked out from the output of
cargo metadata.

With this change, when a dependency is configured for a specific
platform, its dependencies are by default also configured for that
specific platform, unless they explicitly have a different platform
attached to them.

This makes it easier to translate crates.io packages for building with
non-cargo build systems, because this platform-specific behaviour of
feature resolution is now observable in cargo metadata, rather than
requiring those systems to track and re-implement feature resolution
themselves with regard to platforms.

Fixes #9863.

[rust-highfive]

r? @ehuss

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

What happens if a dependency is target-specific by one path through the dependency tree, but not target-specific by another path through the dependency tree?

[illicitonion]

What happens if a dependency is target-specific by one path through the dependency tree, but not target-specific by another path through the dependency tree?

Currently not the correct thing! I've locally added a test that it should either represent that as one unified platform:

"dep_kinds": [
  {
    "kind": null,
    "target": null
  }
]

or noting that there were multiple platforms that led to this dep:

"dep_kinds": [
  {
    "kind": null,
    "target": "x86_64-apple-darwin"
  },
  {
    "kind": null,
    "target": null
  }
]

Working on updating the code - thanks for the feedback!

[illicitonion]

@rustbot label +S-waiting-on-author -S-waiting-on-review

[rustbot]

Error: The feature relabel is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please let @rust-lang/release know if you're having trouble with this bot.

[illicitonion]

After chatting with @ehuss (thanks!) we ascertained:

1. The current metadata being output is correct for resolver v1, which didn't factor platform-feature combinations into its resolution.
2. Resolver v2 would fix this, but there's currently no plan to expose resolver v2 output from metadata (see https://rust-lang.github.io/rfcs/2957-cargo-features2.html#cargo-metadata).

Closing this for now in favour of working out how to express resolver v2 output from cargo metadata.