Splitting up `compiletest::runtest`

[Nicholas-Baron]

Subtask to #60302.

• RunPassValgrind is practically useless (valgrind is not installed on CI, and the tests are just run in run-pass mode). The right approach here is likely to refactor it as a modifier atop the regular run-pass tests -- it looks like the code generally just mirrors the RunPass mode, other than setting the runtool to valgrind. That mode can be enabled in the configuration of the test with // use-valgrind or something like that.
• Move diff computation out into a separate module (DiffLine, Mismatch, make_diff, ...)
• Move read2_abbreviated to the read2.rs module
• Move DebuggerCommands and their parsing out to a separate file, alongside check_debugger_output (which is similarly parsing code).

I suspect this set of changes is likely harder, and might not get to <3000 lines; there's likely more cleanup work possible, though. This module has grown pretty organically over the last ~10 years -- there's a lot of small bits that can be adjusted to make things better. There's probably also subtle inconsistencies between various functions that would likely be nice to clean up and unify, and filing PRs for those would be helpful -- likely some care is needed, perhaps even some small test updates, but overall a good goal.

You might also be interested in #40713, as a somewhat larger project.

Originally posted by @Mark-Simulacrum in #89240 (comment)

[Nicholas-Baron]

@Mark-Simulacrum I have started reading fn run_rpass_test and fn run_valgrind_test. While they are mostly similar, there seem to be some key differences.

1. Valgrind tests are hardcoded to EmitMetadata::No, while Rpass tests seem to possibly emit metadata.
2. Valgrind changes the run tool just before executing the compiled test.

I can see simplifying run_valgrind_test to a call to run_rpass_test. However, I do not think that is what was originally intended.

[Nicholas-Baron]

@rustbot label: +C-cleanup.

[Mark-Simulacrum]

I think there's room for unifying the two -- we already have some support for running tests under a wrapper for e.g. android testing, so I imagine we might be able to reuse parts of that perhaps.