feat: Cast numeric (non int) to timestamp

[coderfender]

Which issue does this PR close?

Closes ##3560 .

Rationale for this change

Adding support for further more native cast support.

1. Float / Double cast to Timestamp (with ANSI support)
2. DecimalType -> Timestamp cast (with ANSI support)
3. Boolean -> Timestamp cast

This should more or less close out the cast matrix in terms of support (barring other not planned casts such as Timestamp -> Int etc)

What changes are included in this PR?

How are these changes tested?

1. Enabled unit tests in CometCastSuite.scala and added new ones (along with benchmarking scripts) on the rust side to test cast at all Eval Modes

[coderfender]

@andygrove I moved the 'assertDataFrameEquals' inside cast test to leverage existing Try and ANSI checks . This should help us gain confidence with native code and perhaps merge it

[andygrove]

Test failure:

- cast FloatType to TimestampType *** FAILED *** (323 milliseconds)
  org.apache.spark.SparkException: Job aborted due to stage failure: Task 1 in stage 2197.0 failed 1 times, most recent failure: Lost task 1.0 in stage 2197.0 (TID 2396) (localhost executor driver): org.apache.comet.CometNativeException: [CAST_INVALID_INPUT] The value 'NaN' of the type "DOUBLE" cannot be cast to "TIMESTAMP" because it is malformed. Correct the value as per the syntax, or change its target type. Use `try_cast` to tolerate malformed input and return NULL instead. If necessary set "spark.sql.ansi.enabled" to "false" to bypass this error.

[coderfender]

Thank you @andygrove There seems to be failure per spark version after I fixed the error message handling. I am making changes to fix tests with the right error message

[coderfender]

it seems like there is some regression between Spark's cast from Float / Double to Timestamp in terms handling extreme values . Investigating into this

[coderfender]

Only spark 4 test is failing and it seems like we might not be using right exception parsing

[parthchandra]

Only spark 4 test is failing and it seems like we might not be using right exception parsing

Would you like to wait forhttps://github.com//pull/3580 ?

[coderfender]

@parthchandra sure !

[coderfender]

@andygrove , marking it as a draft to not accidentally merge until @parthchandra 's PR is reviewed

[parthchandra]

@coderfender I've marked this as ready for review if you could rebase and resolve the ci failures.

[coderfender]

Sure thank you

[coderfender]

It seems like the errors are transient @parthchandra . Can you please rerun failed actions whenever you get a chance

[coderfender]

@parthchandra @andygrove , Rebased with main . Please review whenever you get a chance . Thank you

[parthchandra]

lgtm. (pending ci)

[coderfender]

Thank you