WIP: move the 'record all toolstates' list into rustbuild

[RalfJung]

Currently, we still build Miri on beta/stable branches to record its toolstate. That seems rather unnecessary. This is a beginning of an attempt to fix that.

However, I think I have to give up here... I have no idea if this execute_cli_for_paths makes any sense; the control flow in rustbuild is entirely impossible to follow.^^ For some reason --dry-run does not work for my new target (it does nothing). Maybe that is because of this execute_cli; I tried to understand the existing dry_run logic but it is very strange (if this is not a dry run then the first thing we do is set dry_run to true?!??) and there are no comments explaining what happens.

I am pretty sure what I have so far is wrong; the code in toolstate.rs all assumes that all tools have a state recorded in the JSON:

rust/src/bootstrap/toolstate.rs

Line 182 in c724b67

for (tool, _) in STABLE_TOOLS.iter().chain(NIGHTLY_TOOLS.iter()) {

and this loop looks like it makes similar assumptions:

rust/src/bootstrap/toolstate.rs

Line 125 in c724b67

for (tool, submodule) in STABLE_TOOLS.iter().chain(NIGHTLY_TOOLS.iter()) {

@Mark-Simulacrum I think someone who actually understands the maze that is rustbuild needs to complete this. It would take me forever to figure this all out, I have no idea how to test any of this with reasonable effort, and it's just not enough of a problem I think to warrant that amount of effort.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

This line should also have a comment (I can just guess what happens here).

[RalfJung]

Closing this as I do not plan to continue working on it; opened #74709 to track the underlying problem.