Cargo 1.52 causes a regression in dylib behaviour

Problem
Since Cargo 1.52, a change in behaviour of how dylibs are compiled has resulted in valid projects now failing to compile with rust 1.52. This is a little bit confusing because it compounds with an issue in the rust compiler but hopefully we can work around that.

Steps

1. Clone this repo: https://github.com/alexkornitzer/dylib-errors/tree/error/nested
2. Build with 1.51 we get the expected linker failure, we can circumvent this with hacks
3. Build with 1.52 we now get dependency satisfaction errors

error: cannot satisfy dependencies so `std` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `compiler_builtins` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `libc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `unwind` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `cfg_if` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `hashbrown` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_demangle` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `addr2line` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `gimli` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `object` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `panic_unwind` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `bar` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: aborting due to 16 previous errors

error: could not compile `serverctl`

To learn more, run the command again with --verbose.

Possible Solution(s)
Originally we only had to handle this bug: https://github.com/rust-lang/rust/issues/82151. In this case the work around was to make sure that the dependant libraries were rlibs so that we compile down to a single dylib. Now with 1.52 we cant even get to this stage as cargo is blocking on dependency resolution.

As noted in the issue above, I assume we are getting to the stage here where we need a system in cargo that lets us specify which dependencies in the tree are what crate type. For example:

hyper = ['rlib', 'dylib']
mysharedlib = ['dylib']

where mysharedlib uses hyper, I want hyper to build as `rlib` and mysharedlib as `dylib` currently both would be compiled as dylibs resulting in satisfaction errors.

Notes

Output of cargo version:
cargo 1.52.0 (69767412a 2021-04-21)

Clone the linked nested-repository example and reproduce the dependency-resolution errors with Cargo 1.51 and 1.52. Compare the two builds and investigate Cargo's dylib and rlib dependency handling; done means the valid project can proceed past dependency resolution under Cargo 1.52 without the reported errors.