Investigate workspace-level dependencies

[BD103]

Good stuff. I'd like to look into workspace-level dependencies at some point too.

Originally posted by @alice-i-cecile in #12313 (comment)

Workspace-level dependencies allow for consistent dependency versions across multiple crates. They can be handy for keeping popular libraries, such as serde, syn, toml_edit and more in sync and reduce dependency duplication.

They can be specified with:

# Root Cargo.toml
[workspace.dependencies]
serde = "1.0.99999"

And can be used by a crate with:

[dependencies]
serde = { workspace = true }
# or
serde.workspace = true

[BD103]

I want to be clear that I think this is worth investigating, but is not necessarily going to be implemented and approved. It may end up as a giant list of dependencies in an already massive Cargo.toml and lots of bikeshedding about which dependencies deserve this treatment.

But then again, please try it out and let us know how it goes.

[Kanabenki]

IMO if workspace dependencies are to be used, the rule should be clear and simple to enforce, like putting every dep as a workspace dependency, or putting any dep used by more than one crate as a workspace dep. Not sure how easy it would be to do but the best would be to enforce the chosen rule in CI.

[BD103]

Compile fail tests are incompatible with all workspace-inherited configuration, in their current form. That will need to be resolved before this issue can move forward.