… over interner

Previously, errors for crates with the same name would only distinguish them by the span of the source:
```
note: `HashMap<_, _, _, _>` is defined in crate `hashbrown`
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
note: `HashMap<u32, u32>` is defined in crate `hashbrown`
   --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
```

When the same version of the crate is loaded twice, this isn't particularly helpful. Additionally
show where the .rlib was loaded from (in this case one was loaded from the sysroot and the other
from a cargo target dir).

This is the only place aside from the global_ctxt query where it is
stolen.

…ustc_type_ir, r=davidtwco

Derive `TyEncodable`/`TyDecodable` in `rustc_type_ir`

when `derive(TyEncodable)` or `derive(TyDecodable)` sees an `I` type parameter on a struct that has no `'tcx`, then parameterize the `TyEncoder`/`TyDecoder`'s interner over that variable rather than `TyCtxt<'tcx>`.

Also, emit where clauses for fields rather than generics.

Use the correct span when emitting the `env!` result

The span used for the `env!` resut changed in 1.73, due to rust-lang@75df62d (from rust-lang#114014).

This prevents [a lint in `plrustc`](https://github.com/tcdi/plrust/blob/main/plrustc/plrustc/src/lints/builtin_macros.rs#L54-L60)[^1] from working well, because the resulting span is not inside the  region where the lint is `#[deny()]`ed.

[^1]: Perhaps worth noting that the `env_macro` diagnostic item comes from [the std fork used with PL/Rust](https://github.com/tcdi/postgrestd/blob/rust-1.73.0/library/core/src/macros/mod.rs#L944).

Unfortunately, I have no idea how to write a test for this since I don't think we can have a custom lint in a test. A suggestion was made to use a custom proc macro for it, but that seems pretty involved (frankly, I might not have time to do it).

r? `@davidtwco` (since they're the author of the PR with the regression)

P.S. We generally try to avoid bothering upstream about PL/Rust-specific stuff (we don't want to nag), but this seems like an actual bug, since the other similar macros, such as `option_env` use the other span (and are lintable as a result).

Distinguish crates with the same name in type errors

Previously, errors for crates with the same name would only distinguish them by the span of the source:
```
note: `HashMap<_, _, _, _>` is defined in crate `hashbrown`
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
note: `HashMap<u32, u32>` is defined in crate `hashbrown`
   --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
```

When the same version of the crate is loaded twice, this isn't particularly helpful. Additionally show where the .rlib was loaded from (in this case one was loaded from the sysroot and the other from a cargo target dir).

Fixes rust-lang#110055.

Remove from vacation and compiler review group

Staying on the types review rotation, but staying off the general review queue is good for me right now.

Also move `@compiler-errors` since he's a full member now.

Couple of small changes

These are unrelated to each other, but they are each small enough that opening separate PR's doesn't make sense to me either.

* Remove a place where the parse driver query is stolen.
* Update an outdated doc comment
* Use correct crate name in `-Zprint-vtable-sizes` when using `#![crate_name = "..."]`.