Maintain default deny-multiple-versions list

[Swatinem]

In general, deny-multiple-versions is nice to have.
But there is also use-cases like global contexts, where having multiple versions of the same crate can actually lead to wrong behavior.

Using sentry as an example, it happens quite frequently that version X is used to capture panics, but version Y is the one that is configured to send reports to sentry.
Since the versions are different and thus have two incompatible global contexts, the result is that panics are not being sent upstream, and the crate malfunctions for the users.
This was brought up yet again for Sentry here: getsentry/sentry-rust#661

This problem is not unique to sentry, but in general for crates using global contexts, like tracing, various metrics related crates, etc.

---

It might be nice to maintain an explicit default deny-list in cargo-deny for such crates which is stronger than the default warn level.

[Jake-Shadle]

I don't think I would ever add something like that to cargo-deny as it would be too confusing for users, and would only help those who actually user cargo-deny, not the many who don't, meaning crates such as yours would still get reports. That being said I wouldn't be against adding a metadata field for cargo-deny that it can use to warn/error for users if they do use cargo deny, eg.

[package.metadata.cargo-deny]
# Having multiple versions of this crate can cause a user's crate/workspace to malfunction, they need to align on one version
multiple-versions = "deny"