Query: Translate aggregate over grouping element in separate pass

[smitpatel]

Design:

• Introduce SqlEnumerableExpression - a holder class which indicates the SqlExpression is in form of a enumerable (or group) coming as a result of whole table selection or a grouping element. It also stores details about if Distinct is applied over grouping or if there are any orderings.
• Due to above DistinctExpression has been removed. The token while used to denote Distinct over grouping element were not valid in other parts of SQL tree hence it makes more sense to combine it with SqlEnumerableExpression.
• To support dual pass, GroupByShaperExpression contains 2 forms of grouping element. One element selector form which correlates directly with the parent grouped query, second subquery form which correlates to parent grouped query through a correlation predicate. Element selector is first used to translate aggregation. If that fails we use subquery form to translate as a subquery. Due to 2 forms of same component, GroupByShaperExpression disallows calling into VisitChildren method, any visitor which is visiting a tree containing GroupByShaperExpression (which appears only in QueryExpression.ShaperExpression or LINQ expression after remapping but before translation) must intercept the tree and either ignore or process it appropriately.
• An internal visitor (GroupByAggregateChainProcessor) inside SqlTranslator visits and process chain of queryable operations on a grouping element before aggregate is called and condense it into SqlEnumerableExpression which is then passed to method which translates aggregate. This visitor only processes Where/Distinct/Select for now. Future PR will add processing for OrderBy/ThenBy(Descending) operations to generate orderings.
• Side-effect above is that joins expanded over the grouping element (due to navigations used on aggregate chain), doesn't translate to aggregate anymore since we need to translate the join on parent query, remove the translated join if the chain didn't end in aggregate and also de-dupe same joins. Filing issue to improve this in future. Due to fragile nature of matching to lift the join, we shouldn't try to lift joins.
• To support custom aggregate operations, we will either reused IMethodCallTranslator or create a parallel structure for aggregate methods and call into it from SqlTranslator by passing translated SqlEnumerableExpression as appropriate.
• For complex grouping key, we cause a pushdown so that we can reference the grouping key through columns only. This allows us to reference the grouping key in correlation predicate for subquery without generating invalid SQL in many cases.
• With complex grouping key converting to columns, now we are able to correctly generate identifiers for grouping queries which makes more queries with correlated collections (where either parent or inner both queries can be groupby query) translatable.
• Erase client projection when applying aggregate operation over GroupBy result.
• When processing result selector in GroupBy use the updated key selector if the select expression was pushed down.

Resolves #27132
Resolves #27266
Resolves #27433
Resolves #23601
Resolves #27721
Resolves #27796
Resolves #27801
Resolves #19683

Relates to #22957

[ColinZeb]

Is this expected to be released to 7.0 prview5?
Is there any plan to release to 6.0.5?