-Z build-std with unified workspace

[Ericson2314]

If I'm not misreading the Cargo code:

• We currently have separate workspace for the user's project std
• We resolve them separately and then combine the unit graphs

I don't think this is a good approach, long term:

• It's very unlike the rest of Cargo, and exercising a bunch of cases that wouldn't be otherwise possible. This is a recipe for bugs.
• When user crate features effect std features (#4 + https://github.com/rust-lang/cargo/issues/5002), resolution is necessarily intertwined.

Conversely, we might inject the crates and (explicit and implicit) stdlib deps to create a unified workspace. We would also combine the lock files to create a lockfile for the combined workspace with the materialized. Now, this will be a bunch of work up front, but I think it comes with a bunch of benefits:

• It's not adding expressive power: one could also manually combine the workspace, lockfile, and add the stdlib deps and then run Cargo on it. This means no new code paths downstream of the workspace combination.
• Since everything is resolved at once, std features affected by project crate features

I also wonder if it might help with https://github.com/rust-lang/wg-cargo-std-aware/issues/23#issuecomment-762466564. Combining the workspaces and lockfiles is also a "big global change", so maybe it's OK to use source for mirroring just in that case?

[lygstate]

What's the plan to stablize -Z build-std?

[Ericson2314]

Hopefully not until these changes are done...