Figure out a way to do out-of-band releases of crates in the cargo repo

[ehuss]

Ever since #14202, the process for publishing cargo libraries to crates.io is done via a workflow triggered when a tag is created. This works great for regular releases of Rust. However, there are times when we need to publish a crate in this repository independent of a Rust release, which does not work very well (or at all).

For example, we need to publish a patch version of cargo that only affects API users, and does not affect the cargo binary shipped in the stable release. Or, there are crates like home or rustfix that are not strictly tied to Rust releases.

The primary problem is that tags can now only be created by promote-release, which prevents us from tagging and running the release process. If we want to do a release of something, we have to get the release team to manually do it, and AFAIK there is no way to add a tag anymore (since it would trigger a release we don't want).

Generally we want:

• The ability to release specific crates independent of the Rust release process.
• The ability to tag those releases.
• A requirement that at least two team members approve the release.
• A notification of some kind to alert when a release is made.

We have discussed a few different approaches to implement this, such as:

• Use GitHub workflow dispatches to generate a little GUI to select crates to publish, and rely on the workflow to handle things and to publish a notification. This does not help with the "require approval" problem.
• Have a file in the repo listing crates to publish (and the associated commit), with a workflow that will auto-publish any new entries in that file. This solves a few issues, like requiring approval, notifications (via regular PR notifications). However, something about it feels a little odd.
• Change the publish workflow so that it looks at the name of tag to determine what to publish (instead of just blindly trying to publish everything). We would still need to figure out a system for approval and notification.

See also #12033 which is a related issue where managing version numbers is currently a pain.

cc @pietroalbini