fix(optimizer): bound planning-time regex compilation

[goutamadwant]

Which issue does this PR close?

• Closes Slow logical planning (>1s) for regexp_like with nested {N} quantifiers #22185.

Rationale for this change

Pathological constant regexes can spend the regex engine's full runtime compilation budget during constant folding, making logical planning take seconds. Disabling folding for every regex would also penalize ordinary patterns, so this change gives planning a smaller compilation budget and defers only expensive literals to execution.

What changes are included in this PR?

• Add a defaulted ScalarUDFImpl::should_evaluate_const hook so immutable UDFs can defer expensive literal evaluation in both logical and physical simplification.
• Apply a 256 KiB planning-time regex size limit to regexp_like and regex operators while retaining the existing runtime limit.
• Prevent deferred regex subtrees from being evaluated indirectly through parent expressions.
• Keep nonconstant regex expressions off the compilation-preflight path and inspect literal arguments by reference without cloning them.
• Preserve ordinary constant folding and existing flag, syntax-error, and NULL behavior.

What is the testing strategy for this PR?

• Added logical optimizer, physical simplifier, scalar-UDF, and SQL planner regressions for ordinary and pathological patterns, aliases, flags, NULL inputs, and nonconstant expressions.
• cargo test -p datafusion-expr -p datafusion-functions -p datafusion-optimizer -p datafusion-physical-expr
• cargo test -p datafusion expensive_regexp_like_is_deferred_to_execution --test core_integration
• cargo test --profile=ci --test sqllogictests -- regexp/regexp_like.slt
• Contributor-guide extended workspace test suite with avro, json, backtrace, extended_tests, recursive_protection, and parquet_encryption features.
• Repository lint steps: rustfmt, workspace Clippy, Taplo, license headers, typo checks, Prettier, workflow policy checks, and rustdoc with warnings denied.
• A local debug planning harness running the issue-shaped expression 20 times took 5.37 seconds with the 10 MiB runtime budget and 0.17 seconds with the 256 KiB planning budget, approximately 31.6 times faster.

Are there any user-facing changes?

Planning now defers unusually expensive constant regexes to execution instead of spending the runtime compilation budget while optimizing the query. Ordinary constant regexes continue to fold. This also adds a defaulted ScalarUDFImpl::should_evaluate_const extension point; existing UDF implementations keep their current behavior.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.22222% with 31 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.63%. Comparing base (3a4c310) to head (ca30c6e).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
...imizer/src/simplify_expressions/expr_simplifier.rs	83.33%	12 Missing ⚠️
...on/physical-expr/src/simplifier/const_evaluator.rs	74.28%	8 Missing and 1 partial ⚠️
datafusion/physical-expr/src/simplifier/mod.rs	89.39%	7 Missing ⚠️
datafusion/expr/src/udf.rs	66.66%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #24917    +/-   ##
========================================
  Coverage   81.62%   81.63%            
========================================
  Files        1123     1123            
  Lines      409637   410092   +455     
  Branches   409637   410092   +455     
========================================
+ Hits       334383   334780   +397     
- Misses      55624    55633     +9     
- Partials    19630    19679    +49     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.