parser: parse IS [NOT] DISTINCT FROM (null-safe comparison)

[chiradip]

What

x IS [NOT] DISTINCT FROM y is valid, null-safe-comparison SQL, but the IS handler only recognized IS [NOT] NULL / TRUE / FALSE / UNKNOWN and silently dropped the DISTINCT FROM tail — leaving the predicate as its bare left operand x, so the WHERE effectively vanished (a silent wrong result).

The parser leg of full IS [NOT] DISTINCT FROM support (the user asked for end-to-end support; analyzer and binder legs follow in their repos).

How

• Parse it into a BinaryExpr whose operator text is "IS DISTINCT FROM" / "IS NOT DISTINCT FROM" — the same text-carried-operator convention the binder's map_binary_op already uses for every other comparison.
• Append two ast::BinaryOp enum values, IsDistinctFrom / IsNotDistinctFrom (existing values preserved), for the downstream legs.
• A malformed IS DISTINCT with no FROM now errors instead of dropping the predicate.

Before / after

WHERE x IS DISTINCT FROM y — before: WhereClause → ColumnRef('x') (3 trailing tokens, DISTINCT FROM y gone); after: WhereClause → BinaryExpr('IS DISTINCT FROM') → [x, y].

Tests

test_parser_expr_hardening: IS DISTINCT FROM / IS NOT DISTINCT FROM build the binary comparison over both operands; IS DISTINCT without FROM is rejected; IS NULL / IS TRUE regressions intact. Full suite 37/37 green.

Downstream

The analyzer will type IS [NOT] DISTINCT FROM as Boolean, never-NULL; the binder's map_binary_op will map the operator text to the new enum values and lower it. Those PRs bump their parser pin to this commit.

Part of the parser-layer robustness pass (CASE fixes are in #46; IN-without-parens and the set-operation drops follow).