Support the libpq options connection parameter

[quinnj]

Adds libpq's options connection parameter (and the PGOPTIONS environment default). The value is passed through to the server in the startup packet exactly as libpq sends it, so options='-c search_path=myschema' sets the default schema for the session, as requested on Discourse (https://discourse.julialang.org/t/libpq-jl-in-2026-maintenance-status-and-postgresql-alternatives/139495/11).

What changed

• options is a keyword on Postgres.Connection, DBInterface.connect, ConnectionPool, ConnectionParams, and DSN/URI strings. It is no longer in the "accepted and ignored" set, so options=... is honored instead of rejected.
• Sent as the options startup parameter, after application_name. An empty value is not sent, matching libpq. NUL bytes are rejected like the other startup strings.
• Because it rides in the startup packet, it applies before the first query and after an automatic reconnect with no SET replay.
• The driver's own client_encoding=UTF8 startup parameter is applied by the server after options, and the reported encoding is still verified, so a conflicting -c client_encoding=... cannot break decoding (covered by a test).
• Docs: README, index, manual (example), support policy (PgBouncer note: options is accepted since PgBouncer 1.20, and search_path inside it is tracked by default only when the server reports it, i.e. PostgreSQL 18+; older servers need track_extra_parameters).
• Version bump to 2.1.0.

Tests

• DSN parsing: keyword form, quoted value with spaces, URI-escaped form, PGOPTIONS default and override, ConnectionParams keyword.
• NUL rejection before any connection is made.
• Integration (Docker): SHOW search_path after connect and after a reconnect; DSN form with two switches; conflicting client_encoding still ends as UTF8; empty value connects; an unknown parameter surfaces as Postgres.Error with SQLSTATE 42704.

🤖 Generated with Claude Code