internal: port rust-analyzer to new Salsa

[davidbarsky]

This PR ports rust-analyzer to the new Salsa. It is big, partially incomplete, and best reviewed commit-by-commit. I will be rebasing often.

(Why new Salsa? It unblocks a lot of work described in #17491.)

Migration Approach

To get rust-analyzer compiling and passing tests, this PR did the following:

• With @nikomatsakis's help, I created db-ext-macro to mimic rust-analyzer's usage of old Salsa's query groups. Over time, rust-analyzer will migrate to new Salsa's idioms, moving away from the query group pattern. For additional details on the differences between old Salsa and new Salsa, please refer to this document.
• @Veykril ported crates/span to new Salsa, which makes use of self-referential interning. This is needed to support macro hygiene.
• New Salsa's structs typically have a 'db lifetime. However, the presence of the 'db lifetime made migrating a large number of interned structs challenging, hence feature: add #[salsa::interned_sans_lifetime] macro salsa-rs/salsa#632.

With these changes, all tests were passing (no correctness issues!), analysis-stats produced the same results as rust-analyzer on the old Salsa, and—critically—the new Salsa-powered rust-analyzer was usable as my daily driver. Unfortunately, memory usage was too high. I'm really grateful to the following folks who helped fix that regression:

• @ShoyuVanilla reduced rust-analyzer's memory usage on analysis-stats from 8 gigabytes to 4 gigabytes by through https://lgithub.com/salsa-rs/salsa/pull/614/.
• @ChayimFriedman2 and @Veykril made further improvements to Salsa's memory usage, which reduced usage by around 575 megabytes.
• Chayim implemented #[salsa::enum], which reduced memory usage by about 150 megabytes and made rust-analyzer's usage of new Salsa more idiomatic.
• I reenabled LRU, which reduced memory usage by an additional gigabyte.

Performance

• On rust-analyzer analysis-stats, new Salsa is slightly slower and uses slightly more memory.
  • On bfb8127, new Salsa uses 2201mb of memory, whereas old Salsa uses ~2000 megabytes.
• On crates/rust-analyzer/src/integrated_benchmarks.rs, new Salsa is slightly faster on both cold and warm updates. These benchmarks should probably be more rigorous, but new Salsa was consistently faster.

Things to Fix Before to Merging

There's a few things to do before this change is merged:

1. Reintroduce debug item printing. However, this is blocked on feature: Add support for dumping database contents salsa-rs/salsa#640 and some additional changes inside of rust-analyzer, but they're not complicated changes.
2. Figure out why the changes in the enum/#[salsa::supertype] commit cause tests to fail to type confusion in the underlying Salsa pages. Chayim is working on root-causing this, but if he's unable to determine the cause, I can make the enum changes a separate pull request.
3. Release db-ext-macro.
   1. I'd like to rename db-ext-macro to something else, or have it live in Salsa. I'm unsure which option I'd prefer right now.
4. Release the new Salsa to crates.io.

Acknowledgements

This wouldn't have been possible without the assistance of many folks including @ChayimFriedman2, @ShoyuVanilla, @nikomatsakis, and @Veykril. I'm sure I'm forgetting some people, to whom I apologize.

[davidbarsky]

Chayim fixed the test failures: this was due us mixing and matching Salsa interning with rust-analyzer's own, home-grown interning. He put it succinctly here:

My macro also implements traits like Eq and Hash. And it implements them by hashing the ID only, because I thought it will be more efficient.
But have we global, unrelated to salsa, interning. For example, that's how we intern Tys. And this global interning will persist even after we switch dbs. But in different dbs, different IDs can map to different kinds!
So we might switch the type of an AdtId, for example, because we mapped it to the incorrect interned key!

As a short-term fix, he's required interned values to implement PartialEq and friends. Longer-term, we'll move this interner into new Salsa.