Improve convertToGpu diagnostics and unbloat GpuOverrides

[gerashegalov]

As of branch-24.06, GpuOverrides.scala is a file of ~4800 Lines of Code (and growing) consisting of numerous replacement rules.

In the center of the rule is an instance of the Function type

doWrap: (INPUT, RapidsConf, Option[RapidsMeta[_, _, _]], DataFromReplacementRule)
          => SparkPlanMeta[INPUT]

which is almost uniformly provided inline compiling down to an anonymous class. Hence, whenever there is an exception in convertToGpu akin to #881

we cannot determine which replacement rule is throwing the exception based on the stack trace alone

at com.nvidia.spark.rapids.GpuOverrides$$anon$95.$anonfun$convertToGpu$8(GpuOverrides.scala:1221)

without having to look at the source code from which the class was compiled

spark-rapids/sql-plugin/src/main/scala/com/nvidia/spark/rapids/GpuOverrides.scala

Lines 1216 to 1222 in d2abd35

	expr[SortOrder](
	"Sort order",
	(a, conf, p, r) => new BaseExprMeta[SortOrder](a, conf, p, r) {
	// One of the few expressions that are not replaced with a GPU version
	override def convertToGpu(): Expression =
	a.withNewChildren(childExprs.map(_.convertToGpu()))
	}),

Note that the original stack trace of #881 does not mentionSortOrder

This issue proposes a convention to have the function instance be nested in a companion object reflecting in its name the Exec, Expression being replaced. This way we can determine the expression, exec causing the issue without matching the line numbers of the stack trace to the right git hash of GpuOverides.

When this function is implemented in a companion object where the corresponding GPU implementation lives, GpuOverrides will become smaller and the rules more compact and clear.

See #10839 for a potential solution.