This is to bring us into conformance with the [Rust crate ownership
policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo-credential-1password` is declared as Experimental as it is
intended for the community but I was unsure if we wanted to commit to
full support for it. In my mind, the ideal thing to do would be to
expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the
ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended
for the wider ecosystem and I didn't see a reason to declare it
experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared
as Intentional as they are both used internally and intended for
others to use for logic that integrates with cargo/registries.
I wondered about these being Experimental or Internal instead.
fix(add): Improve error when adding registry packages while vendored
### **What does this PR try to resolve?**
When a vendored directory is established, cargo add no longer adds new packages. Instead, it tries to translate a package name into a package that already exists in the vendored directory.
[More details](https://github.com/rust-lang/cargo/issues/10729#issue-1260548746)
Since `@epage` has done most of the work, here I do the rest of the finishing work.
Improves the error from #10729
### **How should we test and review this PR?**
The implementation procedure is as follows:
https://github.com/rust-lang/cargo/issues/10729#issuecomment-1191633351
Test steps：
1. Try to get an arbitrary crate and execute `cargo vendor` command.
2. Configure the vendor directory in .cargo/config.toml.
3. Add `alter-registry` to the config.toml file.
```
[registries]
alter-registry= { index = "XXX" }
```
4. run the same `cargo add` command.
```
cargo add another-crate --registry alter-registry
```
Respect `package.rust-version` when generating lockfile, so that
a package with an old MSRV will never get an incompatible lockfile,
even when using the latest Cargo.
Users are still able to edit the `version` field in the lockfile
manually, if they intend to switch to a specific lockfile version.
To implement rust-lang/rfcs#3516, we need to decouple the resolver's
behavior from the unstable flag. Since the code path is now dead, I
went ahead and removed it.
This concentrates all of the "prefer this version" logic previously
handled with `try_to_use` and `prefer_patch_deps` parameters into a
struct that hides both the reason a package version might be preferred
and the form that preference took (Dependency or PackageId). Besides
simplifying `RegistryQuerier::query` slightly, this invites further
refinements to version preferences to support new cargo features.
When selecting among several versions of a paackage, prefer versions
from `[patch]` sections over other versions, similar to how locked
versions are preferred.
Patches come in the form of a Dependency and not a PackageId, so this
preference is expressed with `prefer_patch_deps`, distinct from
`try_to_use`.
