Parser: fix exponential parse time on expression-named function arguments

[moshap-firebolt]

On dialects with expression-named function arguments
(supports_named_fn_args_with_expr_name, e.g. PostgreSQL and MSSQL),
parse_function_args speculatively parses the whole argument expression to
detect the name => value form, then on failure rewinds and re-parses the
same expression on the unnamed path. Because CAST and CASE fall back to
function-call parsing when their reserved-word form fails, both passes recurse
through the remaining chain, so on inputs like CAST(CASE (CAST(CASE (... work
doubles per level. Parsing the leading expression once and then checking for a
named-argument operator removes the redundant traversal; the resulting AST is
identical on valid SQL.

Measured on PostgreSqlDialect with with_recursion_limit(256), release
build. Input: SELECT + CAST(CASE ( repeated N times + ) repeated 3N:

N	Before	After
10	1.8 s	781 us
15	>30 s	967 us
20	>30 s	1.6 ms
25	>30 s	2.3 ms

A wildcard can never be a named-argument name, so it is routed straight to the
unnamed path, preserving prior behavior. This also makes the "reserved keyword
as a bare function argument" error consistent across dialects (SELECT MAX(interval) now reports the same position regardless of named-argument
support); test_reserved_keywords_for_identifiers is updated accordingly.

Regression test in tests/sqlparser_common.rs runs a 30-level chain with a 5 s
timeout (hits the timeout pre-fix, finishes in well under a millisecond
post-fix); bench under sqlparser_bench.

[iffyio]

LGTM! Thanks @moshap-firebolt!

[iffyio]

@moshap-firebolt could you take a look at the conflict on the branch?

[moshap-firebolt]

@moshap-firebolt could you take a look at the conflict on the branch?

@iffyio - done!