Reconfigurator planning: Cleanup and clarifying the planner/builder split

[jgallagher]

Internally Reconfigurator's planner is split into two main types (with many supporting types): Planner and BlueprintBuilder. As we've continued to grow the planner, whether a given method or bit of logic should belong to one or the other has been a steady source of confusion. I think the intent is that Planner should be "the thing invoked by Nexus that makes decisions based on system state", and BlueprintBuilder should be "a relatively 'dumb' Rust-style builder that allows for easy blueprint editing". In particular, BlueprintBuilder should be usable (and is used!) in many contexts that the Planner isn't: reconfigurator-cli, tests, etc., and can be used to make changes to a blueprint that would be nonsense in the context of planning more generally.

We've chipped away at various cleanup tasks along the way. Some opportunities for additional cleanup; I'm sure other folks have more and more may come up if and when we dig into some of these:

• Some limited resources (e.g., external IP addresses) are managed via the BlueprintResourceAllocator type. As currently implemented, this type is constructed after expungement (so it can reuse resources that have been freed up by that process) but before any new zones are added, but it's very non-obvious: BlueprintBuilder internally holds a OnceCell<BlueprintResourceAllocator> that it constructs on demand, so in practice this is constructed during the first zone add that needs an allocated resource. We should clean this up: it's fragile and not at all obvious that we're (ab)using a OnceCell specifically to delay decision making until the right type.
• Currently BlueprintBuilder holds the parent blueprint (reasonable), the latest inventory collection (a little weird), and a PlanningInput (very weird: shouldn't that be input to the Planner, not the lower-level builder). Could we trim this down to just the parent blueprint?
• Decisions made by the planner result in an inconsistent mix of logs, blueprint comments, and details in the planning report, depending on the age of the code (we initially only had logs, then had logs and comments, then had all three), whether it's been updated recently, whether the code in question has a related spot in the planning report, etc.

Ideally we could take a stab at some or all of this before we need to make significant changes to the planner following R17 (e.g., adding planner bits to drive non-disruptive update).