☂ Improve linter test reliability and maintainability

[pq]

Our current approach to rule testing leans heavily on expectations being communicated in the source via special comments (e.g., // LINT). This works very well for the simple cases but has accumulated some technical debt over time.

1. the test infrastructure cares only about the specific lint-under-test and discards all other diagnostics. This has caused a bunch of confusion over the years (see e.g., skip nullable iterables in avoid_function_literals_in_foreach_calls linter#2752 (comment)).
2. when testing logic that depends on more than one compilation unit we take an integration test approach, spawning a process and expressing expectations in terms of expected CLI output -- this is slow, unwieldy to debug and brittle wrt to modifications (basically the trouble with golden files).

To get this under control, I'd like to consider a few changes:

• consider checking rule tests for analyzer diagnostics (and possibly failing in their presence) #58448
• move all test data source that has deliberate diagnostics (e.g., parse errors) to dedicated (in-memory) tests
  • create an in-memory rule test harness #58521
  • migrate test logic
• migrate our approach to multi-file tests (mis-labeled "integration" tests) to in-memory tests a la analyzer
  • create an in-memory rule test harness #58521
  • migrate existing "integration" tests