End game for find usages

Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/End.20Game.20for.20Find.20Usages

Consider this code:

fn foo() {}

macro_rules! m {
    () => {
        $crate::foo()
    };
}

mod inner {
    fn f() {
        m!();
    }
}

Does the m!() call constitute a usage of the foo function? Under our current model, the answer is no: a usage requires a literal foo present in the source code. This is because find usages works by pruning a super-set of textual occurrences (https://rust-analyzer.github.io/blog/2019/11/13/find-usages.html), and there's no textual occurrence to prune here!

There are two ways we can deal with it, which lead to dramatically different architectures.

First approach is to stick with our current model, and just implement heuristics that would flag a potential usage in the macro definition. Note that no heuristic would work for procedural macros.

Second approach is to always eagerly expand all macros for find usage. This is still much cheaper than typecheking everything, but is way costlier than our current text-based pruning.

If we go with the second approach, that has implications for the overall architecture. For example, if we are going to expand all the macros anyway, we might want to dump expansions to disk and treat them as inputs.

Start with the linked find-usages blog post and the Zulip thread to understand the current text-based pruning model. Compare the proposed macro heuristics with eager expansion, including the procedural-macro limitation and the possibility of storing expansions as inputs. Done means selecting and documenting an architecture for macro-aware find usages.