`cargo add` should support adding an inherited dependency to a workspace

[heaths]

Problem

We are using a workspace to centrally managed certificate configuration including dependencies. This makes it easier to ship some - perhaps all - workspace packages on separate schedules with approved dependency versions (likely the latest minor or patch version). Unfortunately, cargo add - which we expect most crate developers will use - cannot add a dependency to a workspace.

If our workspace is Cargo.toml and member crates are under sdk/ e.g., sdk/core/Cargo.toml, what should happen somehow is:

1. The dependency and any enabled features are added to the workspace Cargo.toml under [workspace.dependencies].
2. An inherited dependency i.e., name = { workspace = inherit } is added to whatever dependency section is chosen e.g., [workspace] by default or [dev-dependencies] when --dev is specified.

Proposed Solution

Ideally, cargo add just works without additional command line switches. This makes it easier in a monorepo with many different contributing teams that don't have to think about different paradigms than they are used to. Perhaps some configuration in .cargo/config.toml e.g.,

[dependencies]
inherit = true

If lieu of or even in addition to, it seems that cargo add {dependency} --package {package} --manifest-path {workspace cargo.toml} should do this. Currently it does not, and seems to ignore the --manifest-path. If I don't use --package and use just --manifest-path, I get an error:

error: `cargo add` could not determine which package to modify. Use the `--package` option to specify a package. 
available packages: {package list}

Notes

May be related to #12208.

[heaths]

If we can agree such a feature makes sense and, on a design, I'd be happy to work on this.

[weihanglo]

I vaguely remember there were some relevant discussions somewhere on Zulip. Could we have links to those?
(Or I remember it wrongly 😅)

[Muscraft]

I believe #10608 is related/covers the same issue

[epage]

Going to close in favor of #10608 it is covering the same need and we should have one place for discussing resolving of that need, rather than dividing it per potential solution.

[heaths]

Sorry. I looked prior to opening this and didn't find anything seemingly relevant besides the issue I linked. I'll add thoughts there. Ideally, we don't need a new flag.