Added reverse map that tells us for a given dependency and its preferred format,
what were the parent crates that requested that dependency+format combination.

(type annotations are to help rust-analyzer as much as humans.)

…tes to prefer dynamic linkage on.

Note: carrying an empty set here is *not* the same as `-C prefer-dyanmic=no`
(and the latter is the default behavior for `rustc`). As discussed in detail in
the comments for `enum PreferDynamicSet` (and also in the comments of
`rustc_metadata::dependency_format`), `-C prefer-dynamic=no` asks the compiler
to guess what linkage to use, and it currently guesses all static first, and if
that fails, then it prefers dynamic linkage for all crates that provide both
dynamic and static libraries.

Using an empty set for `-C prefer-dynamic`, on the other hand, means the
compiler should never prefer dynamic linkage over static linkage, even if that
means it won't be able to successfully link the build product.

…dency tracking.

…hen we fail due to repeated static library.

…te,...` flag can be used to resolve issue 82151.

These differ from the diamonds-*.rs in a couple of ways:
 * The most foundational library is being compiled to multiple crate output types, and
 * The most foundational library is being compiled to a `cdylib`, not a `dylib`.

These two details seemed to be critical for reproducing the exact set of
unfortunate link-time behaviors that we observed on issue 82151, as illustrated
by the family of tests named `issue-82151-serverctl-*.rs`.

----

issue-82151-serverctl-prefdyn.rs works around ld-binary specific details by
adding extra normalization to test, including normalizing stage number in output.

These tests specifically show the effects of having both rlib and dylib library
variants present, as well as what happens when you mix in various settings for
`-C prefer-dynamic=...`.