feat(sql): generalize ClickHouse-builtin stub registration to ScalarUDF

[zzylol]

Summary

• Adds a CLICKHOUSE_SCALAR_BUILTINS table to crates/sql-function-catalog ({ name, arity }, no RewriteKind -- see below) covering ten ClickHouse-only scalar builtins the bgp_jan2024_workload corpus (feat: add bgp_jan2024_workload SQL corpus test (200 queries, ASAPQuery PR #561) #219) surfaced as "unknown function" Plan failures: splitByChar, toDate, match, toStartOfHour, toStartOfWeek, toStartOfMinute, toStartOfFiveMinutes, toStartOfInterval, startsWith, positionCaseInsensitive.
• Adds clickhouse_scalar_builtin_stub_udf(name, arity) -> ScalarUDF in crates/frontend-sql/src/sql/mod.rs, mirroring clickhouse_builtin_stub_udaf's "dead code by construction" reasoning: the stub's invoke/invoke_batch are unreachable because this front end only ever uses DataFusion for planning/type-checking, never physical execution.
• Registers a stub ScalarUDF per catalog entry in SqlLowerer::build_context(), alongside the existing per-entry AggregateUDF loop.
• No FunctionRewrite is added for these, unlike the aggregate case (SQL: extract dialect builtin-function catalog into independent, generatable data (inspired by polyglot-sql-function-catalogs) #225/feat(sql): extract function-name catalog, generalize uniqExact/countIf rewrite #227): expr.rs's Expr::ScalarFunction arm already lowers any scalar call generically to Unresolved::FunctionCall { name, args }, so teaching DataFusion's planner to accept the name is the entire fix.

Arities and return types (for sanity-checking against real ClickHouse semantics)

Function	Arity	Arrow return type	Why
splitByChar(sep, s[, max_substrings])	2-3	List<Utf8>	Real return is Array(String); a plain Utf8 element list is close enough for planning.
toDate(expr)	1	Date32	Matches actual corpus usage (toDate(timestamp), always 1 arg).
match(haystack, pattern)	2	Boolean	ClickHouse returns UInt8 (0/1), but every corpus use is a WHERE/boolean-context predicate.
toStartOfHour(dt[, tz])	1-2	Timestamp(Millisecond, None)	Matches the Timestamp convention types.rs::dtype_to_arrow already uses.
toStartOfWeek(dt[, mode[, tz]])	1-3	Timestamp(Millisecond, None)	ClickHouse's optional mode + timezone args.
toStartOfMinute(dt[, tz])	1-2	Timestamp(Millisecond, None)
toStartOfFiveMinutes(dt[, tz])	1-2	Timestamp(Millisecond, None)
toStartOfInterval(dt, INTERVAL x unit[, tz])	2-3	Timestamp(Millisecond, None)	The INTERVAL x unit clause parses as a single expr argument.
startsWith(s, prefix)	2	Boolean	ClickHouse returns UInt8; treated as a predicate here.
positionCaseInsensitive(haystack, needle[, start_pos])	2-3	UInt64	1-based match position, 0 if not found.

Arities were checked against actual corpus call sites (grep'd out of bgp_jan2024_rrc00_200_query_workload.yaml) as well as ClickHouse's documented signatures, so the stub Signature accepts every real call shape in the corpus plus documented optional trailing args (timezone, mode, max-substrings, start-position).

Corpus tally shift

bgp_jan2024_workload's pinned aggregate tally (corpus_lowering_matches_the_pinned_aggregate_tally):

Category	Before	After
Lowered	97	145
Plan	92	40
NotImplemented	5	7
UnsupportedFeature	6	6
Other	0	2
Schema / Parse	0 / 0	0 / 0

The +2 in NotImplemented is exactly the companion gap the issue itself flags: splitByChar(...)[-1]-style calls (and a couple of other array/map-index uses) now plan far enough to hit the pre-existing map/array-index NotImplemented gap instead of failing earlier at "unknown function".

The +2 in Other is a new, separate pre-existing gap this fix surfaces rather than causes: two toStartOfInterval(timestamp, INTERVAL 15 minute)-shaped queries now plan far enough that types::scalar_value_to_asap has to convert the INTERVAL literal (DfScalarValue::IntervalMonthDayNano), which it doesn't support yet -- out of scope for this issue (which is about function names, not literal-expression conversion), so it's pinned rather than chased down, the same way the array-index gap is.

Also updates bgp_analytics's pinned per-query outcome table: query 7's toStartOfInterval(...) call itself now plans fine, so planning proceeds into its nested toIntervalMinute(5) argument -- an unregistered ClickHouse builtin outside this issue's 10-function scope -- and fails there instead (Expected::UnknownFunction("tostartofinterval") -> Expected::UnknownFunction("tointervalminute")).

Explicitly out of scope (per the issue)

• lagInFrame (window function, SQL: ClickHouse's lagInFrame window function needs window-frame modeling #231) and argMax (new aggregate semantic, SQL: ClickHouse's argMax has no AggIntent representation #232).
• Any actual runtime semantics for what these functions compute.
• The map/array-index NotImplemented gap and the INTERVAL-literal Other gap noted above.

Test plan

• cargo build --workspace --all-targets
• cargo test --workspace (all green)
• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings

Closes #230