Allow cargo +rust-version build|test|...

Problem you are trying to solve

Now that rust-version is stable it makes sense to have a CI task/job that asserts this commitment. In that case, one would need to set up a CI config that runs tests on the selected Rust version. Usually, it means that the specific version will be specified twice

1. rust-version in Cargo.toml
2. Somewhere in CI configuration.

And they need to be in sync to make sense. This is where extra work is required and that may be avoided.

Solution you'd like

I suggest teaching cargo to understand the +rust-version parameter, alongside the +stable, +nightly, and friends. When specified it will cause cargo to use the Rust toolchain referenced in the rust-version parameter. (And installing it on demand as it does today when used with other +toolchain parameters).
If used for crates that lack rust-version parameter it will fall back to otherwise default toolchain configured for this crate.

As a result, the potential disagreement between CI and rust-version will be avoided completely, better usability, less time wasted, etc

Notes

This issue was originally opened as rust-lang/cargo#10012, but rustup is the right place to solve it

Start by tracing rustup's handling of +stable, +nightly, and other +toolchain parameters, then inspect how the requested rust-version value could be obtained from Cargo.toml. Determine the behavior for crates with and without rust-version, including on-demand installation, and verify the resulting toolchain selection across build and test commands.