Bitwise `&` and `->` group differently in the PostgreSQL and MySQL/Generic dialects

Start in src/dialect/mod.rs with the default precedence table, then compare it with PostgreSqlDialect::prec_value in src/dialect/postgresql.rs:176-184 and the PostgreSQL gram.y rule cited in the issue. Add a tree-level regression test for a -> b & c, since SQL round-trip tests cannot detect the grouping, and run the full suite to verify the change.

& and -> have the same precedence in PostgreSQL but not in the default precedence table, so the
same expression produces two different trees depending on dialect:

& is the only row that disagrees.

Cause

The default table in src/dialect/mod.rs has:

Precedence::Ampersand => 23,
Precedence::Caret => 22,
Precedence::Pipe => 21,
Precedence::Colon => 21,
Precedence::PgOther => 21,

PostgreSqlDialect::prec_value instead maps Ampersand, Pipe, Colon and PgOther all to
PG_OTHER_PREC (src/dialect/postgresql.rs:176-184), which matches gram.y, where & is just a
generic Op and shares one left-associative level with ->:

%left  Op OPERATOR RIGHT_ARROW '|'

So Pipe already agrees with PgOther in the default table (both 21), and Caret is legitimately
above it, but Ampersand at 23 is left as the sole outlier.

Candidate fix

-            Precedence::Ampersand => 23,
+            Precedence::Ampersand => 21,

The full suite passes unchanged with that applied, so no existing test pins the current grouping —
which is also why this went unnoticed. Display for Expr::BinaryOp emits no parentheses, so a
mis-grouped tree round-trips to the original SQL and verified_expr / verified_stmt cannot catch
it; a test would have to assert on the tree.

Open question, possibly a separate issue

For MySQL the fix above is necessary but not sufficient. MySQL's -> / ->> take a quoted JSON path
on the right-hand side, so there is nothing for MySQL to resolve — col->'$.a' + 1 can only mean
(col->'$.a') + 1. sqlparser parses that right operand as a full expression at PgOther, giving
col -> ('$.a' + 1), so -> under-binds in MySQL against +, *, ^ and friends, not just &.
Making that correct probably means a MySQL-specific precedence for the arrow operators rather than
another adjustment to the shared row, so I've kept it out of scope here — happy to split it out if
a maintainer would prefer it tracked separately.

Surfaced while working on #2436. Related: #2460.