Parser: fix exponential parse time on speculative prefix parsing

[LucaCappelletti94]

parse_prefix speculatively tries the next token as a reserved-word expression head and, on failure, falls back to treating it as an unreserved identifier. Both arms can independently recurse into the same downstream position. Two complementary caches now break the 2^N exploration: an outer per-position failure cache catches chains where both arms fail at every level, and a per-arm cache on the reserved-word try_parse catches chains where the arm fails but the fallback succeeds.

Supersedes #2349 (named-arg chain) and #2351 (NOT-prefix chain). Does NOT supersede #2350 (compound-keyword .not-b chain, which lives in parse_compound_expr).

Same machine, release build, apache main 182eae81 baseline:

Input	Dialect	Size	Before	After
if(current_time(...x, n=30	PG	394 B	>60s	591us
.foo(t--,i) chain, n=25 (was #2349)	PG	308 B	>60s	550us
x-not-b. chain, n=30 (was #2351)	Generic	247 B	>60s	1.45ms
case\t- chain, n=30 (new)	SQLite	181 B	>60s	700us
cAse#f-#9-cAse#f... fuzz artifact	PG	142 B	86ms	486us

Regression tests in tests/sqlparser_common.rs and benches under sqlparser_bench cover the if(current_time and case-case shapes.

[LucaCappelletti94]

Me watching yet another fuzzer crash: