To keep this simple, we are leveraging `unicase` for case-insensitive
comparisons which I've been using for years on other projects.

This also opens the door for us to add cross-platform compatibility
hazard warnings about multiple paths that would write to the same
location on a case insensitive file system.  I held off on that because
I assume we would want rust-lang#12235 first.

This does mean we can't test the "no manifest" case anymore because the
one case (no pun intended) I knew of for hitting it is now gone.

To keep things simple, especially in getting a `Hash` implementation
correct, I'm leveraging `unicase` for case-insensitive
comparisons which is an existing dependency and I've been using for
years on other projects.

This also opens the door for us to add cross-platform compatibility
hazard warnings about multiple paths that would write to the same
location on a case insensitive file system.  I held off on that because
I assume we would want rust-lang#12235 first.

This does mean we can't test the "no manifest" case anymore because the
one case (no pun intended) I knew of for hitting it is now gone.

fix(package): Recognize and normalize `cargo.toml`

### What does this PR try to resolve?

This solution is a blend of conservative and easy
- Normalizes `cargo.toml` to `Cargo.toml` on publish
  - Ensuring we publish the `prepare_for_publish` version and include `Cargo.toml.orig`
  - Avoids dealing with trying to push existing users to `Cargo.toml`
- All other cases of `Cargo.toml` are warnings
  - We could either normalize or turn this into an error in the future
  - When helping users with case previously, we've only handle the `cargo.toml` case
  - We already should have a fallback in case a manifest isn't detected
  - I didn't want to put in too much effort to make the code more complicated to handle this

As a side effect, if a Linux user has `cargo.toml` and `Cargo.toml`, we'll only put one of them in the `.crate` file.  We can extend this out to also include a warning for portability for case insensitive filesystems but I left that for after #12235.

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

A PR at a time will show how the behavior changed as the source was edited

This does add a direct dependency on `unicase` to help keep case-insensitive comparisons easy / clear and to avoid riskier areas for bugs like writing an appropriate `Hash` implementation.  `unicase` is an existing transitive dependency of cargo.

### Additional information

Fixes #12384

[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60cargo.2Etoml.60.20on.20case.20insensitive.20filesystems)

feat: Add `rustc` style errors for manifest parsing

#12235 is tracking user control over warnings. One part of that is making `cargo`'s diagnostic system output messages in the style of `rustc`. To make it so that `cargo` doesn't have to manage a formatter and renderer, I decided to use [`annotate-snippets`](https://crates.io/crates/annotate-snippets), which matches `rustc`'s style well (at one time it was meant to be the formatted for `rustc`).

To get this work kicked off, it was suggested to me that we should start with styling manifest parsing errors, and that is what his PR does.

What manifest parsing errors look like after this change:
![image](https://github.com/rust-lang/cargo/assets/23045215/0eb388b9-8d72-48ad-84a9-585160995078)

---

Note: `cargo` does not currently match `rustc` in color (#12740), `rustc`  specifies their colors [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/lib.rs#L1755-L1768) and [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/emitter.rs#L2689-L2723). I used `annotate-snippets` default colors which match what `rustc` currently uses for colors. I did this as a stopgap while I work to unify the colors used between `rustc` and `cargo`.

---

Note: the error messages come directly from `toml` and can be quite long. It would be nice if we could put some of the message below the highlight but this would require changes to `toml`.
Example:
```
error: invalid type: integer `3`
 --> Cargo.toml:7:7
  |
7 | bar = 3
  |       ^ expected a version string like "0.9.8" or a detailed dependency like { version = "0.9.8" }
  |
```

feat: Add `rustc` style errors for manifest parsing

#12235 is tracking user control over warnings. One part of that is making `cargo`'s diagnostic system output messages in the style of `rustc`. To make it so that `cargo` doesn't have to manage a formatter and renderer, I decided to use [`annotate-snippets`](https://crates.io/crates/annotate-snippets), which matches `rustc`'s style well (at one time it was meant to be the formatted for `rustc`).

To get this work kicked off, it was suggested to me that we should start with styling manifest parsing errors, and that is what his PR does.

What manifest parsing errors look like after this change:
![image](https://github.com/rust-lang/cargo/assets/23045215/0eb388b9-8d72-48ad-84a9-585160995078)

---

Note: `cargo` does not currently match `rustc` in color (#12740), `rustc`  specifies their colors [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/lib.rs#L1755-L1768) and [here](https://github.com/rust-lang/rust/blob/740cea81d6e34fc03c4495890e29f1c5ecb40b96/compiler/rustc_errors/src/emitter.rs#L2689-L2723). I used `annotate-snippets` default colors which match what `rustc` currently uses for colors. I did this as a stopgap while I work to unify the colors used between `rustc` and `cargo`.

---

Note: the error messages come directly from `toml` and can be quite long. It would be nice if we could put some of the message below the highlight but this would require changes to `toml`.
Example:
```
error: invalid type: integer `3`
 --> Cargo.toml:7:7
  |
7 | bar = 3
  |       ^ expected a version string like "0.9.8" or a detailed dependency like { version = "0.9.8" }
  |
```

fix(toml): Don't warn on unset Edition if only 2015 is compatible

### What does this PR try to resolve?

The warning doesn't help towards the stated goal if the only MSRV-compatible Edition is 2015 (plus, if you're MSRV is that old, you likely know better).

This also fixes a problem in #13505 where we were suggesting to set a field that might require an MSRV bump which may be unactionable to silence and we avoid warnings without an actionable way of silencing until #12235 gives us a general means.

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

### Additional information

This was discussed in
- #13505
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/warn.20on.20missing.20.60edition.60.20field.20in.20Cargo.2Etoml

feat(tree): Control `--charset` via auto-detecting config value

### What does this PR try to resolve?

This tries to generalize `cargo tree --charset` so any part of cargo's output can use it.  For example,
- `cargo search` could use this for fancier tables
- `cargo add` could use this for fancier feature lists
- #12235 could use this for fancy rendering like miette does (CC `@Muscraft` )
- Progress bars could use fancier characters <-- this is what I'm personally working towards

This builds on the idea from #12889 that we can use fancier terminal features so long as we have good auto-detection and provide users an escape hatch until the auto-detection is improved or in case they disagree.

As a side benefit
- `cargo tree` will auto-detect when the prior default of `--charset utf8` is a good choice
- Users can control `cargo tree --charset` via `.cargo/config.toml`

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

This is gradually introduced through the individual commits.

### Additional information

feat: Add a basic linting system

This PR adds a basic linting system, the first step towards [User control over cargo warnings](#12235). To demonstrate the system, a lint for #12826 is added. It supports controlling cargo lints via the `[lints.cargo]` table. Lints can be controlled either by a group or individually.

This is meant to lay down some fundamental infrastructure for the whole linting system and is not meant to be fully featured. Over time, features will be added that will help us reach a much more solid state.

Unused dependencies cleanup

The implementation of #12826 was used as a demonstration for #12235, in #13621. The demonstration implementation was far from ideal and was lacking a few features. This PR makes the implementation "feature complete", and fixes known bugs with the initial implementation.