Simplify polonius location-sensitive analysis

[lqd]

This PR reworks the location-sensitive analysis into what we think is a worthwhile subset of the datalog analysis. A sort of polonius alpha analysis that handles NLL problem case 3 and more, but is still using the faster "reachability as an approximation of liveness", as well as the same loans-in-scope computation as NLLs -- and thus doesn't handle full flow-sensitivity like the datalog implementation.

In the last few months, we've identified this subset as being actionable:

• we believe we can make a stabilizable version of this analysis
• it is an improvement over the status quo
• it can also be modeled in a-mir-formality, or some other formalism, for assurances about soundness, and I believe @nikomatsakis is interested in looking into this during H2.
• and we've identified the areas of work we wish to explore later to gradually expand the supported cases: the differences between reachability and liveness, support of kills, and considerations of time-traveling, for example.

The approach in this PR is to try less to have the graph only represent live paths, by checking whether we reach a live region during traversal and recording the loan as live there, instead of equating traversal with liveness like today because it has subtleties with the typeck edges in statements (that could forward loans to the successor point without ensuring their liveness). We can then also simplify these typeck stmt edges. And we also can simplify traversal by removing looking at kills, because that's enough to handle a bunch of NLL problem 3 cases -- and we can gradually support them more and more in traversal in the future, to reduce the approximation of liveness.

There's still some in-progress pieces of work w/r/t opaque types that I'm expecting lcnr's opaque types rework, and amanda's SCCs rework to handle. That didn't seem to show up in tests until I rebased today (and shows lack of test coverage once again) when #142255 introduced a couple of test failures with the new captures rules from edition 2024. It's not unexpected since we know more work is needed with member constraints (and we're not even using SCCs in this prototype yet)

I'll look into these anyways, both for future work, and checking how these other 2 PRs would change things.

---

I'm not sure the following means a lot until we have some formalism in-place, but:

• I've changed the polonius compare-mode to use this analysis: the tests pass with it, except 2 cases with minor diagnostics differences, and the 2 edition 2024 opaque types one I mentioned above and need to investigate
• things that are expected to work still do work: it bootstraps, can run our rustc-perf benchmarks (and the results are not even that bad), and a crater run didn't find any regressions (forgetting that crater currently fails to test around a quarter of all crates 👼)
• I've added tests with improvements, like the NLL problem case 3 and others, as well as some that behave the same as NLLs today and are thus worse than the datalog implementation

r? @jackh726

(no rush I know you're deep in phd work and "implmentating" the new trait solver for r-a :p <3)

This also fixes #135646, a diagnostics ICE from the previous implementation.

[rustbot]

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[jackh726]

Happy to review, but don't expect it for 2 weeks :)