This refactors how we deal with items in hir-def lowering.
- It now lowers all of them through an "ExpressionStore" (kind of a misnomer as this point) as their so called *Signatures.
- We now uniformly lower type AST into TypeRefs before type inference.
- Likewise, this moves macro expansion out of type inference, resulting in a single place where we do non-defmap macro expansion.
- Finally, this PR removes a lot of information from ItemTree, making the DefMap a lot less likely to be recomputed and have it only depend on actual early name resolution related information (not 100% true, we still have ADT fields in there but thats a follow up removal).
It should be considered by the edition of the caller, not the callee.
Technically we still don't do it correctly - we need the span of the method name (if it comes from a macro), but we don't keep it and this is good enough for now.
Most paths are types and therefore already are in the source map, but the trait in impl trait and in bounds are not.
We do this by storing them basically as `TypeRef`s. For convenience, I created a wrapper around `TypeRefId` called `PathId` that always stores a path, and implemented indexing from the types map to it.
Fortunately, this change impacts memory usage negligibly (adds 2mb to `analysis-stats .`, but that could be just fluff). Probably because there aren't that many trait bounds and impl traits, and this also shrinks `TypeBound` by 8 bytes.
I also added an accessor to `TypesSourceMap` to get the source code, which will be needed for diagnostics.
So that given a `TypeRef` we will be able to trace it back to source code.
This is necessary to be able to provide diagnostics for lowering to chalk tys, since the input to that is `TypeRef`.
This means that `TypeRef`s now have an identity, which means storing them in arena and not interning them, which is an unfortunate (but necessary) loss but also a pretty massive change. Luckily, because of the separation layer we have for IDE and HIR, this change never crosses the IDE boundary.
`std::env::set_var` will be unsafe in edition 2024, but not before it.
I couldn't quite figure out how to check for the span properly, so for now
we just turn the false positives into false negatives, which are less bad.
