Allow dialects that use -> as an operator to support LAMBDA syntax

[adriangb]

Motivation

supports_lambda_functions() gates two different spellings of the same feature:

• the arrow form, x -> x + 1
• the LAMBDA keyword form, LAMBDA x : x + 1

Because they share one flag, a dialect cannot have one without the other. That
shuts out any dialect that already gives -> a meaning. PostgreSQL is the
obvious case: -> is JSON member access, so turning the flag on silently
reinterprets existing expressions rather than adding a capability.

Concretely, with the flag enabled, a -> 'b' no longer parses as a binary
operator. It parses as a lambda with parameter a and body 'b', because
parse_prefix treats any unreserved word followed by -> as a lambda
parameter. Note ->> is unaffected, so the breakage is partial and easy to
miss.

The LAMBDA keyword form has no such conflict: it does not claim ->.

Change

Adds Dialect::supports_lambda_keyword_syntax(), which gates only the LAMBDA
keyword form, and defaults to supports_lambda_functions().

No existing dialect changes behavior. Dialects that support the arrow form keep
both spellings; dialects that support neither still get neither. A dialect that
uses -> for something else can now override just the new method to get lambdas
without disturbing its operator.

No dialect shipped here opts in; this only makes the capability reachable.

Tests

Two tests in tests/sqlparser_custom_dialect.rs:

• a dialect enabling only supports_lambda_keyword_syntax parses
  lambda x : x + 1 while -> stays a BinaryOperator::Arrow
• a dialect enabling only supports_lambda_functions still accepts both
  spellings, pinning the defaulting behavior

Full suite, cargo fmt --check, and cargo clippy --all-targets --all-features
all pass.

[adriangb]

One could argue for adding fn supports_lambda_arrow_syntax() as well, but I'd hold off until there is a concrete use case for enabling arrow syntax but not lambda syntax.

[adriangb]

I'm split between this (the real regression test I want) and another test using a MyDialect in sqlparser_custom_dialect.rs that enables the two flags. Open to input.