feat: support RLIKE and REGEXP operators

[fmcmac]

Which issue does this PR close?

No existing issue. This PR states the problem and a reproduction below.

Rationale for this change

sqlparser parses expr [NOT] RLIKE pattern and expr [NOT] REGEXP pattern for every dialect, but DataFusion refuses both:

SELECT 'abc' RLIKE '^a';
-- Error: This feature is not implemented: Unsupported ast node in sqltorel: RLike { negated: false, .. }

Expected: true. DataFusion already has the semantics as regexp_like(expr, pattern). Spark, Hive and MySQL users write these operators directly.

What changes are included in this PR?

• SqlToRel plans expr [NOT] RLIKE|REGEXP pattern as [NOT] regexp_like(expr, pattern).
• regexp_like resolves through ContextProvider::get_function_meta, the same lookup as an explicit call. A session that overrides regexp_like gets its override for all 3 spellings. A session without it gets a planning error naming regexp_like.
• Explicit calls and the operators share a new plan_scalar_udf helper. Registered ExprPlanner::plan_scalar hooks therefore see RLIKE, REGEXP and their negations, just as they see regexp_like(...). The helper keeps a planner's result distinct from the default call, so a planner's rewrite is returned as is and only the default call gets the alias for a function called by another name.
• It plans as the function, not Operator::RegexMatch. The unparser renders RegexMatch as ~ for every dialect, while a function call can be renamed per dialect. The built-in's simplify still rewrites it to ~ for execution.
• Docs: RLIKE and NOT RLIKE in the operators guide.

What is the testing strategy for this PR?

• regexp/regexp_like.slt: RLIKE, REGEXP, NOT RLIKE and NOT REGEXP over the shared test data, a NULL subject, a NULL pattern, a column pattern, and row-for-row agreement with regexp_like(...).
• sql_integration.rs:
  • select_rlike_plans_as_regexp_like: registry resolution and plan shape.
  • select_rlike_without_regexp_like: the planning error.
  • select_rlike_with_expr_planner: an ExprPlanner that rewrites regexp_like to ~ applies to the explicit call, RLIKE, REGEXP, NOT RLIKE and NOT REGEXP.
  • select_expr_planner_rewrite_to_other_function: an ExprPlanner that rewrites regexp_like to another scalar function keeps that function's output name, for the explicit call and for RLIKE, with no alias back to regexp_like(...).
• All fail on main.

Are there any user-facing changes?

Yes: RLIKE and REGEXP now plan instead of erroring. Documented in the operators guide. ExprPlanner::plan_scalar now also sees these operators. No public API change.