fix(isthmus)!: keep the declared column order of an aggregate over grouping sets

[alexandrefimov]

Substrait takes the grouping columns of an aggregate to be the distinct grouping expressions in the order they first appear across its grouping sets, while Calcite takes them from a bit set and emits them ordered by field index. Neither direction accounted for that, so a plan whose sets first mention field 1 and then field 0 changed meaning on the way through: a reference to the aggregate's first column reached the column Calcite had put there instead, and its type changed with it.

Both directions now carry the difference in the emit mapping rather than in the shape of the plan. On the way in, the mapping a relation carries is translated into the order the converted aggregate emits, and a relation that emits directly gets the mapping that puts its columns back in the declared order. On the way out, the mapping presents the aggregate's output in Calcite's order, so a parent converted from the same Calcite plan finds its columns where it left them. Neither direction adds a relation the plan did not have, so a plan that already agrees with Calcite round-trips unchanged — which is what Substrait2SqlTest.simpleTestGroupingSets checks, and it is also how I found that fixing only one direction is not enough.

The pre-aggregate projection now reuses one column for a field grouped on by several sets. Two copies of it would each be missing from a grouping set, and Calcite would make both nullable.

Worth a second look, since the change touches a branch that had no coverage: the GROUP_ID branch of SubstraitRelVisitor.visit(Aggregate) used a grouping-field count that included a field shared by several sets more than once, which disagrees with Aggregate.deriveRecordType. It now uses the distinct count. No query reaches that branch — Calcite folds GROUP_ID() into a literal wherever it can work out the answer, including over duplicated grouping sets — so the test that covers it builds the Calcite aggregate directly.

Two more defects in the grouping-set index column came out of the same math and are fixed here. The mapping that keeps that column replaced its index with aggregateCalls.size() - 1, which counts aggregate calls rather than output columns, so what came back was a copy of a grouping column. And the index the relation declares for it counted every mention of a grouping expression, so a field grouped on by several sets shifted it past the end: such an aggregate with a mapping that keeps the index threw ArrayIndexOutOfBoundsException, on main as well. Both counts are over the distinct grouping columns now. What the column holds is still Calcite's folded GROUP_ID() literal, which is #1182.

One difference is left alone: the grouping-set index comes back as an i64. The conversion builds Calcite's GROUP_ID call as a BIGINT while the spec gives the aggregate an i32 column, and Calcite folds the call to a literal of its own type. That is #1162.

Closes #1159