Avoid consolidate in minsmaxes hierarchical

[antiguru]

Like #27068 but for MinxMaxesHierarchical.

Change the rendering of mins-maxes-hierarchical plans to avoid an intermediate consolidate. At the moment, we render plans by forking the inputs, arranging and reducing once side, then concatenating the inputs with negated reduction output, and consolidating the result. This makes sure that we consolidate eagerly, but at the same time does duplicate work: The next operator forms an arrangement, so we could just reuse that instead.

Ths PR implements this pattern, removing one consolidate from each stage, and adding it back after the final stage to ensure the stage's output itself is consolidated. Note that we now apply the hash modulus on uncompacted data, whereas it previously was guaranteed to be consolidated. This might increase the cost of the operator by a factor of 2.

The PR also does some refactorings:

• It applies the initial modulus eagerly to save one operator preparing the hash value.
• It extracts a build_bucketed_stage function to make the code more readable.
• I did a cleanup pass to fix a few things I noticed.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[frankmcsherry]

This looks good. We left some notes, some of which we might want to do or at least record as things to do. Thanks!