fix(splitter): preserve blank lines in parsable SQL

[edjubert]

What kind of change does this PR introduce?

Bug fix.

What is the current behavior?

The statement splitter treats blank lines as statement boundaries. Valid SQL formatted
with blank lines can therefore be split into invalid fragments and reported as syntax
errors.

Fixes #784.

This also addresses the underlying behavior reported in #372, #380, and #780.

What is the new behavior?

Statement splitting now uses two passes:

1. A coarse pass splits on ; and structural statement starts while ignoring blank lines.
2. For fragments containing blank lines, a recovery pass checks whether PostgreSQL can
   parse the fragment:
   • parsable fragments remain intact;
   • unparsable fragments are re-split using blank lines as boundaries.

A blank line now splits SQL only when the complete fragment cannot be parsed.

This preserves recovery for incomplete SQL while typing, including cases such as a
missing ; before BEGIN.

Additional context

• Named parameters are normalized before the parser check, matching workspace parsing.
• The lexer records whether the source contains blank lines, so files without them avoid
  the recovery-path token scan.
• Valid fragments can still be split when their blank-line-separated parts are independently
  valid statements.

Added coverage for:

• blank lines inside a FROM clause;
• blank lines between CTEs and after the final CTE;
• blank lines inside string literals;
• named parameters;
• parser recovery for invalid SQL;
• a missing semicolon before BEGIN.

Validated with:

cargo test -p pgls_lexer -p pgls_statement_splitter
cargo clippy --all-targets --all-features -- -D warnings