feat: comet native scan improvements - Dynamic Partition Pruning

[Shekharrajak]

Which issue does this PR close?

Ref #3510

Rationale for this change

CometNativeScanExec currently falls back to Spark when Dynamic Partition Pruning (DPP) is present. This limits performance for star-schema queries that rely on DPP to prune partitions at
runtime based on dimension table filters.

What changes are included in this PR?

Added DPP support to CometNativeScanExec for V1 native scans
Implemented partition filter evaluation from DPP subqueries

How are these changes tested?

Added DPP benchmark comparing Spark vs Comet native scan performance
Unit tests

$ make benchmark-org.apache.spark.sql.benchmark.CometDPPBenchmark

  OpenJDK 64-Bit Server VM 17.0.13+11 on Mac OS X 26.2                                                                                                                                       
  Apple M4 Max
  Star-Schema DPP Query (5000000 rows, 50 partitions):  Best Time(ms)   Avg Time(ms)   Stdev(ms)    Rate(M/s)   Per Row(ns)   Relative                                                       
  -----------------------------------------------------------------------------------------------------------------------------------
  Spark (JVM) with DPP                                           163            173           9         30.7          32.6       1.0X
  Spark (JVM) without DPP                                        154            164           7         32.4          30.9       1.1X
  Comet (Native) with DPP                                        103            107           3         48.7          20.5       1.6X
  Comet (Native) without DPP                                      98            101           2         50.9          19.6       1.7X