fix(expressions)!: classify boolean binary operators as Predicate

[georgesittas]

Various Binary classes that entered the codebase as functions (RegexpLike, ArrayContains, etc.) now subclass Predicate, so _annotate_binary short-circuits them to BOOLEAN and 14 redundant BOOLEAN returns entries drop out.

Breaking: simplify_parens now strips redundant parens around these operators (NOT (a @> b) becomes NOT a @> b). Verified this is safe w.r.t. precedence on Postgres 18, DuckDB, MySQL, Snowflake and Databricks; nonnull propagation is also restored.

[georgesittas]

This branch was a no-op due to how group_by is constructed:

1. Two loops iterate over keys: loop A at L197–208 decides group_by, loop B at L293–316 reads it
2. To reach this branch, both not (key in group_by) and isinstance(predicate, exp.EQ) must be true
3. The only way for a key to avoid being added in group_by is by the corresponding predicate in the tuple not being an EQ predicate, see L207-208

[github-actions]

SQLGlot Integration Test Results

✅ All tests passed

Comparing:

• this branch (sqlglot:jo/classify_boolean_predicates @ sqlglot 3e41ed0)
• baseline (main @ sqlglot a9c0bea)

Overall

main: 182937 total, 160861 passed (pass rate: 87.9%)

sqlglot:jo/classify_boolean_predicates: 170743 total, 149709 passed (pass rate: 87.7%)

Transitions:
No change

Dialect pair changes: 0 previous results not found, 3 current results not found

✅ All tests passed

[fivetran-kwoodbeck]

Adding Predicate here routes these operators into a parenthesis removal path in simplify_parens that mishandles ~:

Input query (with ArrayContainsAll)

SELECT ~(a @> b) FROM t

simplify() output

SELECT ~a @> b FROM t

~ binds tighter than @>.

[fivetran-kwoodbeck]

Hmm, it actually looks like the same path also mishandles on main: SELECT ~(a = b) simplifies to SELECT ~a = b. Maybe it's a different PR.