feat(cli): add a parse command emitting the libpg_query protobuf

[edjubert]

What kind of change does this PR introduce?

Feature: a new parse CLI command.

What is the current behavior?

There is no way to get the libpg_query parse tree out of the CLI. Consuming PostgreSQL parse trees from another language requires the language bindings or vendor-specific glue.

What is the new behavior?

postgres-language-server parse [FILE] reads a SQL file (or standard input) and writes the parse tree to standard output as a protobuf ParseResult message, the same contract the official language bindings expose. Any tool with a generated pg_query client can decode the output and walk the tree, using the same binary that already formats and checks SQL.

The parse mirrors how the rest of the CLI reads SQL: psql named parameters (:'name', :name) become parser-compatible placeholders of identical byte length, so every location in the tree stays aligned with the input bytes. Parser warnings go to the console; the protobuf on standard output is untouched.

Additional context

Aligns with the protobuf parse-tree direction taken in #639, from the CLI side and for non-Rust consumers: we use this command to feed a Go lineage corpus that decodes the tree with the pg_query_go dictionary, with no cgo and no duplicated parser.

Tests: assert_parse runs the command end to end and decodes its output. One test asserts a decodable ParseResult with the expected statement count; the other asserts that the statement end location falls exactly on the input's semicolon when named parameters are present, pinning the byte-length-preserving substitution.

[psteinroe]

would love to hear more about where and how you use the language server!

thanks for all the great contributions 🫶