Handle recovery for statements with invalid leading tokens

[florinutz]

Bumping the pinned grammar to CrateDB 6.3.2 turned the test suites red on May 23: IndexError in Python, TypeError in JavaScript.

Root cause

6.3.2 made the leading statement optional in the grammar (statements: statement (SEMICOLON statement)* ... → statement?). As a result, a statement whose first token is invalid (e.g. SELCT 2) no longer produces a StatementContext — the parse collapses to error nodes — so sqlparse() returned an empty list and callers indexing [0] blew up. Empty input / a bare ; are now valid, which is the intended upstream change; the parser wrapper just didn't account for it.

Fix

When the parse yields no statements but an error was collected, rebuild from it: emit one Statement carrying the error, then recover the remainder after the first top-level ; (recursing, since the tail can collapse again). Applied identically to the Python and JavaScript targets.

Also in this PR

• Updated the two expected_message assertions to 6.3.2's token set (it now legitimately lists <EOF> and ';').
• Fixed two latent test bugs that only surfaced because empty input is now valid: tests that iterated over a string's characters (Python) / an array's indices (for..in, JS) instead of the query strings.

Known limitation

A bad statement in a non-leading position still derails the statements after it — the older, still-open #28. It's captured here as a strict-xfail (Python) / test.fails (JS) tripwire that will flip the day #28 is fixed.

Checklist

• Link to issue this PR refers to (if applicable): Fixes SQL statement parsing went south on CI on May 23 #284 (refs Second+ statement will not be parsed (as DefaultContext) if first statement is not correct #28)
• Fix applied to both targets (Python + JavaScript)
• Added regression tests; full suites green (Python 21 passed, 1 xfailed; JS 23 passed, 1 expected fail)
• Updated CHANGES.md

Closes #284