cargo add clap@4.1.3 lock to the version specific

[epage]

Problem

If I'm explicitly setting the version requirement, there is likely a reason for it, like MSRV. I shouldn't have to then run cargo update -p clap --precise 4.1.3 after running cargo add.

Proposed Solution

When the version requirement is precise, lock to it

Notes

I implemented support for this in cargo-edit's cargo upgrade, see killercup/cargo-edit#795

[weihanglo]

If we open a URL on crates.io with a precise version, for example https://crates.io/crates/cargo/0.68.0, it will hint us with cargo add cargo@0.68.0.

As a new Rust user, I might just copy the command and then be locked to that version forever accidentally, if this feature gets landed.

The idea is that, users could copy a command from anywhere without thinking about it.

[epage]

So long as we don't commit lockfiles for libs by default, this will only affect programs and only until the user does a cargo update, so I don't think it is all that bad.

I also suspect going to a specific version's page or someone including @ is less likely to happen.

The counter to this is the user intending a specific version and not getting it, like for MSRV.

However, how we handle this is dependent on how we expose #5657 to the user, so I don't think any action should be taken on this until then