Rename, clarify, and document code for "erasing" query values

[Zalathar]

In order to reduce compile times and code size for the compiler itself, the query system has a mechanism for “erasing” and ”restoring” query values in certain contexts. See #109333 for the original implementation.

Unfortunately, the erasure system has very little documentation, and involves a dizzying assortment of similarly-named types, traits, and functions.

This PR therefore renames several parts of the erasure API and implementation to hopefully be clearer, and adds comments to better explain the purpose and mechanism behind value erasure.

Summary of renames:

• fn erase → erase_val (avoiding ambiguity with module erase)
• fn restore → restore_val
• type Erase<T> → Erased<T> (for actual erased values of T)
• trait EraseType → Erasable (for types that can be erased and restored)
• associated type EraseType::Result → Erasable::Storage
• implementation-detail struct Erased<T> → ErasedData<Storage>

There should be no change to compiler behaviour.

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Zalathar]

Erasable goes against the notional convention of naming traits after verbs rather than adjectives, but in this case I find erasable so much clearer that I think it's justified.

[workingjubilee]

certainly can't be worse the status quo, since it wasn't Erase before. what does "EraseType" mean? "you can erase this type"? yeah it implements the trait, doesn't it?

( type Erase simply doesn't make much sense to me. )

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.