Optimize HAVING filter placement for GROUPING SETS queries

[natashasehgal]

When GROUPING SETS are present, HAVING filters on grouping keys are currently kept above
aggregation entirely (D94281152). This is correct but not optimal — the filter should be
pushed between GroupId and Aggregation to reduce rows before the hash table is built.

Three optimization levels based on filter and grouping set properties:

1. Key in ALL grouping sets (never NULLed): move filter below GroupId
2. Key NOT in all sets + null-rejecting filter (e.g., HAVING k > 0): prune grouping sets
   where the key is inactive, then move filter below GroupId
3. Key NOT in all sets + null-allowing filter (e.g., HAVING k IS NULL): filter only between
   GroupId and Aggregation

This requires splitting the aggregation construction in addPostprocess to emit GroupId →
Filter → Aggregation instead of a single Aggregation step. Axiom currently has no mechanism
to place filters between these two operators.