Add support for PIVOT

[martint]

Summary

Adds first-class PIVOT syntax to Trino, eliminating the need to hand-write FILTER aggregation SQL to rotate row values into columns.

SELECT *
FROM sales PIVOT (
    sum(amount) AS total
    FOR month IN (1 AS jan, 2 AS feb, 3 AS mar)
    GROUP BY region
)

PIVOT attaches to the relation tree at the same level as MATCH_RECOGNIZE and supports:

• multiple aggregations per slot, requiring an alias on each;
• single or multi-column pivot keys, with tuple values for the multi-column form;
• arbitrary aggregating expressions in the aggregation slot (e.g. sum(x) - sum(y)), validated by the existing AggregationAnalyzer;
• explicit GROUP BY including GROUPING SETS, CUBE, ROLLUP, and GROUP BY ();
• alias and column-alias on the PIVOT output (PIVOT (...) AS p (c1, c2)).

Two semantic choices align PIVOT with the rest of Trino rather than with other engines' shortcuts:

• Missing GROUP BY implies GROUP BY (): the result is a single row whose only columns are the pivot output columns. To preserve a dimension, name it explicitly in GROUP BY.
• Standard NULL semantics: IN (NULL) produces a column whose = predicate is UNKNOWN — never matches — so the column always carries the empty-input aggregation result.

PIVOT is added as a non-reserved keyword.

Architecture

• The analyzer reads the user-written Pivot AST, calling analyzeExpression on the pivot columns, IN values, GROUP BY expressions, and slot expressions, and runs AggregationAnalyzer.verifySourceAggregations on the slot expressions. It records Analysis.PivotAnalysis: the GroupingSetAnalysis, the GROUP BY DISTINCT flag, the per-output-column descriptors (name + type), and the list of aggregate FunctionCalls (collected via the existing ExpressionTreeUtils.extractAggregateFunctions). It does not synthesize any AST.
• The planner builds the desugared plan in QueryPlanner.planPivot. It projects aggregation inputs (aggregate args, complex grouping expressions, pivot column references, pivot value expressions), coerces, then constructs each value group's FILTER predicate as IR (Comparison + Logical, with a Cast when value/column types differ) and projects it as a boolean symbol. After planGroupingSets, it builds one AggregationNode.Aggregation per (value group, aggregate call) pair with filter set to the matching predicate symbol, and a single AggregationNode containing all of them. The output projection translates each user-written slot expression through a per-group TranslationMap overlay so the same sum(x) resolves to N different output Symbols for N value groups.

PIVOT reuses every existing aggregation, GROUP BY, FILTER, and coercion plan-time rule without introducing a new operator.

The first two commits are pure refactors that decouple analyzeGroupBy and planGroupingSets from QuerySpecification so PIVOT can reuse them. Both have no behavior change for the QuerySpec path.

Test plan

• New TestPivot (19 cases): no/with GROUP BY, multi-aggregation, multi-column keys, expression aggregations, expression IN values, GROUPING SETS / CUBE / ROLLUP / GROUP BY (), NULL semantics, pivot-of-pivot, relation alias with column aliases, plus error paths (arity mismatch, missing alias, duplicate output column, non-aggregating slot).
• New TestSqlParser cases (8) covering each grammar shape including pivot used as an identifier.
• TestSqlKeywords and TestSqlParserErrorHandling updated to include the new PIVOT keyword.
• Existing TestAnalyzer, TestSqlParser, MATCH_RECOGNIZE and aggregation tests continue to pass.
• mvnd verify for the touched modules passes (compile, checkstyle, modernizer, error-prone).

Documentation

• New docs/src/main/sphinx/sql/pivot.md reference page modelled after match-recognize.md.
• Toctree entry in sql.md, cross-reference from select.md, and listing in language/sql-support.md.