refactor(isthmus): visit(Aggregate) duplicates applyRelCommon's composition, so further RelCommon handling would miss it

[nielspardon]

applyRelCommon is the one place that composes a relation's RelCommon handling:

substrait-java/isthmus/src/main/java/io/substrait/isthmus/SubstraitRelNodeConverter.java

Lines 1170 to 1178 in 934a60e

	*
	* @param relNode the node the relation was converted into
	* @param rel the relation being converted
	* @param inputs the nodes this relation's inputs were converted into
	* @return the node, remapped and renamed
	*/
	protected RelNode applyRelCommon(RelNode relNode, Rel rel, RelNode... inputs) {
	return applyOutputNames(applyRemap(relNode, rel.getRemap()), rel, inputs);
	}

visit(Aggregate) hand-inlines the same composition, because the mapping it applies is one it rewrote rather than the one the relation carries:

substrait-java/isthmus/src/main/java/io/substrait/isthmus/SubstraitRelNodeConverter.java

Lines 410 to 413 in 934a60e

	RelNode node = aggregateBuilder.push(child).aggregate(groupKey, aggregateCalls).build();
	// Not applyRelCommon: the mapping applied here is the one rewritten above, not the one the
	// relation carries.
	return applyOutputNames(applyRemap(node, remap), aggregate, child);

The comment explains why the relation's own mapping cannot be used, but duplicating the composition means anything further added to applyRelCommon -- its Javadoc already lists the alias, the statistics, the saved and loaded computations and the common advanced extension as deliberately dropped, so that is where such handling would land -- reaches every relation except the one whose mapping handling is already the most intricate.

An applyRelCommon(RelNode, Rel, Optional<Rel.Remap>, RelNode...) overload that the no-mapping version delegates to would let visit(Aggregate) pass its rewritten mapping and leave one place composing RelCommon.

Found while reviewing #1189.