refactor(lockfile): Make diffing/printing more reusable

### What does this PR try to resolve?

This is prep for #13561 so we can tailor the printing of lockfile changes to each use without a bunch of flags.

### How should we test and review this PR?

### Additional information

This is part of rust-lang#9930 for rust-lang/rfcs#3537

This will make it easier to maintain an MSRV-compliant `Cargo.toml` but
leaves validation up to the user as the resolver will pick newer
versions.
This helps the MSRV-aware workflows enumerated in
rust-lang/rfcs#3537 though it could be confusing to the workflow with an
MSRV-compatible lockfile.
PR rust-lang#13561 at least raises awareness of that discrepancy.

There is an unresolved question on differences in the resolver vs
`cargo add` for dealing with an unset `rust-version`.
However, we are only stabilizing the `cargo add` side which is a very
light two-way door as this is a UX-focused command and not a
programmatic command.

This hasn't gotten much end-user testing but, as its UX focused, that
seems fine.

As such, this seems like it is ready to stabilize.

This is part of rust-lang#9930 for rust-lang/rfcs#3537

This will make it easier to maintain an MSRV-compliant `Cargo.toml` but
leaves validation up to the user as the resolver will pick newer
versions.
This helps the MSRV-aware workflows enumerated in
rust-lang/rfcs#3537 though it could be confusing to the workflow with an
MSRV-compatible lockfile.
PR rust-lang#13561 at least raises awareness of that discrepancy.

There is an unresolved question on differences in the resolver vs
`cargo add` for dealing with an unset `rust-version`.
However, we are only stabilizing the `cargo add` side which is a very
light two-way door as this is a UX-focused command and not a
programmatic command.

This hasn't gotten much end-user testing but, as its UX focused, that
seems fine.

As such, this seems like it is ready to stabilize.

This is part of rust-lang#9930 for rust-lang/rfcs#3537

This will make it easier to maintain an MSRV-compliant `Cargo.toml` but
leaves validation up to the user as the resolver will pick newer
versions.
This helps the MSRV-aware workflows enumerated in
rust-lang/rfcs#3537 though it could be confusing to the workflow with an
MSRV-compatible lockfile.
PR rust-lang#13561 at least raises awareness of that discrepancy.

There is an unresolved question on differences in the resolver vs
`cargo add` for dealing with an unset `rust-version`.
However, we are only stabilizing the `cargo add` side which is a very
light two-way door as this is a UX-focused command and not a
programmatic command.

This hasn't gotten much end-user testing but, as its UX focused, that
seems fine.

As such, this seems like it is ready to stabilize.

feat(add): Stabilize MSRV-aware version req selection

### What does this PR try to resolve?

This is part of #9930 for rust-lang/rfcs#3537

This will make it easier to maintain an MSRV-compliant `Cargo.toml` but leaves validation up to the user as the resolver will pick newer versions.
This helps the MSRV-aware workflows enumerated in
rust-lang/rfcs#3537

### How should we test and review this PR?

As for determining if this is ready for stabilization:

By stabilizing this without the MSRV-aware resolver, this could be confusing to the workflow with an MSRV-compatible lockfile.
PR #13561 at least raises awareness of that discrepancy.
In general there was interest in the RFC discussions to stabilize this ASAP, regardless of what resolver direction we went.

There is an unresolved question on differences in the resolver vs `cargo add` for dealing with an unset `rust-version` (noted in the tracking issue). However, we are only stabilizing the `cargo add` side which is a very light two-way door as this is a UX-focused command and not a programmatic command.

This hasn't gotten much end-user acceptance testing but, as its UX focused, that seems fine (light, two way door)

As such, this seems like it is ready to stabilize.

### Additional information

feat(update): Include a Locking message

### What does this PR try to resolve?

This extends #13561 to `cargo update`.  I previously left it out because the locking message was redundant.  However the `Locking` message has been extended in #13754 to include the resolving policy which can be a useful point of interest (e.g. "why does `cargo update` do nothing? Oh, `-Zminimal-versions` is enabled").

I still left out the message for `--precise` because the user is overriding all of that.

I'd still like to extend all of this to `cargo install` (and maybe all resolves) but that is taking more investigation.

### How should we test and review this PR?

### Additional information

feat(install): Including Locking message

### What does this PR try to resolve?

This extends #13561 to include `cargo install`, like #13759 did for `cargo update`.

As we switch to MSRV-aware resolver, this will help users work out why
MSRV-aware resolving isn't helping them.

This will also make it more obvious if we breaking things when
developing the MSRV-aware resolver.

### How should we test and review this PR?

### Additional information

This still leaves `cargo publish` and a couple other misc situations that I'm intentionally avoiding because
- They hit some weird cases that can confuse the user (e.g. causing `cargo install --locked` to show that 1 package is being added) and we can't distinguish these cases too well from where this is happening
- The value is lower