[datafusion-spark] Add physical implementations for functions that only have simplify()

[coderfender]

Several functions in datafusion-spark currently only implement simplify() and throw errors in invoke_with_args(). This causes issues for downstream projects like Comet that convert physical plans directly without going through DataFusion's logical optimizer

This discussion is to see if we could get consensus on the approach since the functions should both support direct datafusion use cases while also providing easy access to downstream projects like comet / lakesail etc

Some open questions worth discussion

1. Should we keep simplify() alongside invoke_with_args() for optimization benefits when the logical optimizer does run?
2. Concerns about duplicating logic between simplify() and invoke_with_args()?

Related issue: #21959

[coderfender]

Tagging folks who might have an opinion here : @andygrove , @mbutrovich , @comphead , @parthchandra , @shehabgamin , @Jefffrey

[shehabgamin]

I think it's fine to duplicate the logic if needed. This should work for everyone downstream :)

[Jefffrey]

I'm finding it a little confusing where the discussion is meant to be had; I originally raised the query in the Discord, before also mentioning it in the epic:

• [EPIC] Complete datafusion-spark Spark Compatible Functions #15914 (comment)

Then a separate issue was created:

• Some datafusion-spark expressions are missing the physical implementation #21959

But now a discussion is created. Could we align where exactly the discussion is meant to be had.

As for my thoughts, I already put them here:

• [EPIC] Complete datafusion-spark Spark Compatible Functions #15914 (comment)