Fix parsing of the GLOBAL/LOCAL join locality and GLOBAL NOT IN

[therealpandey]

Fixes #292

GLOBAL/LOCAL was consumed in the same switch branch that would otherwise call parseJoinOp, so it acted as a join type of its own rather than a prefix to one. Any real join type after it was rejected, and the two forms that did parse (GLOBAL JOIN, LOCAL JOIN) dropped the keyword from Format(). Separately, GLOBAL claimed IN's precedence unconditionally — so a GLOBAL starting the next join was read as an operator — and parseInfix required IN immediately, leaving GLOBAL NOT IN with no parse path.

SELECT * FROM t1 GLOBAL INNER JOIN t2 ON t1.a = t2.a                                -- was: <EOF> or ';' was expected, but got: "INNER"
SELECT * FROM t1 GLOBAL ANY LEFT JOIN t2 USING (a)                                  -- was: <EOF> or ';' was expected, but got: "ANY"
SELECT * FROM t1 AS x LOCAL FULL JOIN t2 ON x.a = t2.a                              -- was: <EOF> or ';' was expected, but got: "FULL"
SELECT * FROM t1 GLOBAL JOIN t2 ON t1.a = t2.a GLOBAL LEFT JOIN t3 ON t1.a = t3.a   -- was: expected IN after GLOBAL
SELECT * FROM t WHERE a GLOBAL NOT IN (SELECT b FROM t2)                            -- was: expected IN after GLOBAL
SELECT * FROM t1 GLOBAL JOIN t2 ON t1.a = t2.a                                      -- parsed, but Format() lost the GLOBAL

What changed:

• parseJoinRightExpr now reads the locality via a new parseJoinLocality helper, which consumes GLOBAL/LOCAL and then continues into parseJoinOp, prepending the locality to the join modifiers so writeJoinSQL re-emits it. No AST change — JoinExpr.Modifiers already carries the join keywords.
• getNextPrecedence gives GLOBAL IN's precedence only when IN or NOT follows, so a GLOBAL that begins the next join is left for the FROM parser.
• parseInfix accepts an optional NOT after GLOBAL and emits GLOBAL NOT IN, following the existing "NOT " + op handling.
• GLOBAL/LOCAL before ARRAY JOIN is rejected with an explicit message rather than being accepted by the new path.

Verified against clickhouse local 26.8.1.337 over a 643-case matrix of locality × join type × ON/USING/no-constraint, plus GLOBAL IN/NOT IN in WHERE, PREWHERE, HAVING, ORDER BY, CASE and nested subqueries, and global/local used as identifiers and aliases. 262 statements that master rejected now parse; nothing that master accepted is rejected. LOCAL IN, NOT GLOBAL IN, GLOBAL GLOBAL IN, GLOBAL LIKE and GLOBAL ARRAY JOIN are Code: 62 on the server and stay rejected here — those are in TestParser_InvalidSyntax.

Coverage: a new parser/testdata/query/select_with_global_join_locality.sql fixture (only new golden files; no existing golden changed) and AST-shape assertions in precedence_test.go for the join modifiers, the GLOBAL IN/GLOBAL NOT IN operators, and their precedence.

One thing worth flagging, since it is visible in the matrix: a non-CROSS join without ON/USING parses here although ClickHouse requires a constraint. That predates this change — t1 JOIN t2 already parsed — but because 262 locality forms now parse, it reaches more statements than before. GLOBAL LEFT JOIN t2 with no constraint used to fail for the wrong reason and now parses. Requiring the constraint changes how every join parses and rewrites existing golden files, so it belongs in its own change rather than this one.