Breakup test.rs into more-manageable sub-modules

[jieyouxu]

Part of Tracking issue for bootstrap test step cleanups #137178.

Summary of changes

Split up test.rs into smaller, more logically organized sub-modules.

• Primarily code motion, instead of a massive hard-to-navigate and hard-to-comprehend test.rs file.
  • One of the purposes of this is to highlight test steps that seem "special" or "unusual". Hopefully, this makes it easier to add new test steps correctly by making it easier to find similar test steps, and compare the differences w/ more "special" test steps.
• One small change to change testdir to use builder.test_out (to prevent reinventing builder.test_out and having yet another place that might desync in the future).
• Left a couple of FIXMEs backlinking to Tracking issue for bootstrap test step cleanups #137178, intended for follow-ups.
• Added a few module-level doc comments for some of the new test submodules.

More context

• Previous exploratory PR: [EXPLORATORY] bootstrap: break up test.rs into smaller modules by test kind #135072.
• Prior discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Renaming.20test.20step.20structs.

Review advice

• There should be no functional changes.
• The commit history is not as clean as I would like (there's a few instances where I realized a while later that I missed a step or two for a given broken-out module, but rebasing meant a bunch of merge conflicts that were tricky to resolve). That being said, I tried to keep the commits as atomic¹ as possible.
• Best reviewed commit-by-commit.

r? @onur-ozkan

Footnotes

1. For some definition of atomic, I suppose ↩

[jieyouxu]

I may redo this after #137215.

[onur-ozkan]

Looking at the new files, I think they seem more complicated than before. The policy or motivation behind this splitting logic is unclear.

Example of things that are unclear:

• std_tests can also contain cargo tests, but there is a module called cargotest. Where should we put cargo tests of a program?
• Why some tools (like compiletest and rustdoc) have separate module for its tests but not other tools?
• What does cargotest mean? Is it for running cargo tests on projects, or is it for running tests of cargo tool?
• When to create a separate module for tests? What is the right time for it?
• ...the list can go very long.

The separation logic should be very clear and not require us to think too much about when to create a test module or where to place a test.

I'm pretty sure that if we use this structure people will start asking in Zulip threads "Which module should I use to add this test?".

I suggest to keep the module separation as simple and basic as possible.

[onur-ozkan]

@rustbot author

[jieyouxu]

Yeah, I'm not super happy about how this ended up. I'll have to rethink this a bit.

[jieyouxu]

What does cargotest mean? Is it for running cargo tests on projects, or is it for running tests of cargo tool?

cargotest is actually src/tools/cargotest (a mini-crater-at-home thing), which is very confusing indeed (I find this name very unfortunate).

[jieyouxu]

I'll probably revisit this in the future, so closing for the time being.