Allow binary-only dependencies in metadata

[illicitonion]

A number of projects, such as https://github.com/google/cargo-raze
consume the output of cargo metadata when generating input to other
build systems, such as Bazel and Buck. Typically, these projects use a
Cargo.toml file as the input to drive their work, and it can be useful
to express to these systems that a binary is required as part of the
build.

If such a dependency happens to have a lib target, sufficient dependency
information happens to be exposed via the resolve field to recreate the
dependency structure adequately.

However, for binary-only targets, that entire branch of the dependency
tree is cut off, making it hard to recreate this information.

This PR adds an option to cargo metadata to allow rendering these
subtrees, describing these deps as of kind "binary". This isn't really a
concept in cargo-proper, but may become one via
rust-lang/rfcs#3168 and/or
rust-lang/rfcs#3028 - this output format is
forwards-compatible with these proposals.

In an RFC 3028 world, binary deps would appear as dep_kind "binary",
and cdylib or staticlib deps would appear as new DepKind variants.
We'd probably add a new value of the flag, declared, and set that to
be the default. We may also want to deprecate the
include-if-no-library-dep value, and make these ignored binary deps a
hard error (replacing the existing warning log).

In an RFC 3168 world, there's an interesting metadata question to have -
there are (at least) three reasonable options in terms of handling
metadata:

1. Require a direct dependency on any package whose binary deps are
   being used from the crate which uses them - this gives a nicely
   restricted search space, and allows for nicely curated metadata
   output.
2. Allow any transitive package dependencies to be used as binary deps -
   this may significantly expand the output produced, but would model
   the implementation of the feature.
3. Require explicitly tagging binary deps as being used as binary deps -
   this looks a lot like RFC 3028, and would tend in that direction.

[rust-highfive]

r? @Eh2406

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

[ehuss]

The Cargo team discussed this in our meeting, and we have decided to close this out. Cargo currently explicitly does not support binary-only dependencies (and will warn about them). We would prefer for progress on something like RFC 3028 to play out and see how binary dependencies work out. We posted a comment at #9992 (comment) with some thoughts on how this information could get exposed in cargo metadata.

If you really still want to get this information, it may be somewhat possible to obtain from the Package description (though takes a little more work).

[illicitonion]

That's great, thanks for discussing it, and I look forward to this information coming in #9992!