refactor: Remove `rust_2024_compatibility` lint group
The `rust_2024_compatibility` lint group was added as a way to be compatible with `Rust`. This group is meant to be used when switching to the 2024 edition (usually enabled by `cargo fix --edition`). Since we are not going to be interacting with `cargo fix` in the standard way to fix edition lints, this group is not needed at this time. Removing this will (slightly) reduce the complexity of working on things for the 2024 edition.
This assumes that if any of the machine applicable fixes in
a diagnostic suggestion is a duplicate, we should see the
entire suggestion as a duplicate.
fix(package): Normalize paths in `Cargo.toml`
### What does this PR try to resolve?
On the surface, this resolves problems that aren't too big of a deal
- Clean up redundant information in paths (e.g. `.////.//foo.rs` being `foo.rs`) which is just visual
- Switch paths with `\` in them to `/`
However, this is prep for #13713 where these will be a much bigger deal
- If the user does `./foo.rs`, we might fail to compare that with the list of files included in the package
- We'll generate paths with `\` and need to make sure the packages can still be used on Windows
### How should we test and review this PR?
### Additional information
refactor: Track when MSRV is explicitly set, either way
### What does this PR try to resolve?
This will hopefully help when merging between CLI and config with #13540.
### How should we test and review this PR?
### Additional information
For now, this is more for visual consistency.
However, this blocks #13713 as we need to be able to make these paths
comparable to what is included in the package.
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
Fix github fast path redirect.
This fixes the GitHub fast-path check to look up the sha of a git ref. At some point, GitHub changed the API to redirect to a different URL. Currently cargo is failing the fast-path lookup with 301 response code.
This can be tested in a project with a git dependency, and running `CARGO_LOG=cargo::sources::utils=debug cargo fetch` to verify it is picking up the fast path. This currently can't be tested in CI due to #13563.
refactor(toml): Decouple target discovery from Target creation
### What does this PR try to resolve?
This builds on #13693 so that the resolving of targets is easier to pull out into `resolve_toml` in prep for fixing #13456
### How should we test and review this PR?
### Additional information
