Revisit how eager macros are handled

Right now we do a weird dance:

• We create a macro call for the argument site, immediately expand that into the argument syntax tree
• Then we do what rustc usually does with macro expansion, we walk the tree, expand all macro calls we find and inline those expansion into the tree
• Finally we create a new macro call with a special payload added to it which is this fully expanded tree, which we then intern. This is the actual input to eager macro, its fully expanded input.

For one interning something that changes like this means we'll re-intern on every change, leaking it, but this also feels somewhat weird. In general this is not really how the eager macros in rustc work, they expand their inputs on demand, it is by sheer luck that this tends to be always the full input (except for format_args but there we get around it by using a special custom syntax). It would be nice if we could avoid this weirdness somehow, though the one beneift of this intermediate tracked expansion is that IDE features will simply work for the expanded argument tree. So really the main thing to solve here would be the payload being interned, but salsa doesn't really give us a way to stash this away aside from interning. We could store it within the def-map that computes it, but then we would likely need to eagerly expand the actual invocation as the expand query would then need to access the def map while we are computing the def map forming a cycle

https://github.com/rust-lang/rust-analyzer/blob/9fcaab3704f813415c78eb81296dc254e2599514/crates/hir-expand/src/eager.rs#L44-L110

Start with crates/hir-expand/src/eager.rs, especially lines 44-110, and trace how eager macro inputs are created, expanded, and interned. Read the surrounding expansion and def-map code to understand the possible cycle described in the issue. Done means the eager-macro handling no longer relies on the problematic changing interned payload while preserving the noted IDE behavior.