[EPIC] Improve planning of hash aggregates

[andygrove]

Describe the bug

The epic is intended to outline the work needed to address various limitations in Comet's hash aggregate planning.

The current situation (described in some detail in #1389):

• Comet converts Spark nodes to Comet starting from the leaf node and walking up the tree. When considering whether a partial aggregate should be converted to Comet there is no check to see if the parent would also be supported.
• When Comet is considering converting a final aggregate to Comet, there is a check to see if the partial ran in Comet, and the final will fall back to Spark if this is not the case. This is overly aggressive and we miss out on performance in the case where mixed Comet/Spark aggregates are actually compatible.

This work can be tackled in the following issues:

• Add a planning mechanism to improve the planning so that the final and partial are always considered together, and that we have a way of defining which aggregates are safe to be mixed and which ones must either run entirely in Spark or Comet.
• Fall back to Spark initially for any incompatible aggregates
• Comet falls back to Spark for final hash aggregate in some cases when it could be supported #2894
• Investigate a mechanism to make the incompatible aggregates work (perhaps by creating intermediate projections)
• For aggregates that currently have incompatible buffer formats between Spark and Comet (such as Bloom filter intermediate aggregate buffers are not compatible between Spark and Comet #2889), consider fixing the incompatibility.

Steps to reproduce

No response

Expected behavior

No response

Additional context

Here are some known issues when stop falling back for the final aggregate:

Sum/Avg in ANSI mode

When allowing Spark partial with Comet final aggregate, there are test failures in Spark SQL:

[info] - SPARK-28224: Aggregate sum big decimal overflow *** FAILED *** (140 milliseconds)
[info]   org.apache.comet.CometNativeException: [ARITHMETIC_OVERFLOW] decimal overflow. If necessary set "spark.sql.ansi.enabled" to "false" to bypass this error. was not instance of java.lang.ArithmeticException (DataFrameSuite.scala:214)

[info] - SPARK-28067: Aggregate sum should not return wrong results for decimal overflow *** FAILED *** (270 milliseconds)
[info]   Expected exception org.apache.spark.SparkException to be thrown, but no exception was thrown (DataFrameSuite.scala:211)

[info] - SPARK-35955: Aggregate avg should not return wrong results for decimal overflow *** FAILED *** (977 milliseconds)
[info]   Expected exception org.apache.spark.SparkException to be thrown, but no exception was thrown (DataFrameSuite.scala:211)