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.61%. Comparing base (35f58f5) to head (86f9679).

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.61%   81.61%   -0.01%     
==========================================
  Files        1124     1124              
  Lines      411978   412201     +223     
  Branches   411978   412201     +223     
==========================================
+ Hits       336236   336409     +173     
- Misses      55936    55979      +43     
- Partials    19806    19813       +7     

☔ 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.

[jayzhan211]

Thanks @goutamadwant , LGTM