feat(runtime): support caller-owned JDBC connections

[omer-cengel]

Summary

Allow generated query classes to execute on a caller-owned JDBC connection so applications can coordinate multiple generated operations within their own commit or rollback boundary.

Changes

• Add a JdbcQueryExecutor(Connection) construction path while preserving the existing DataSource path and generated APIs.
• Share parameter binding, row mapping, affected-row handling, resource closure, and exception translation between both modes.
• Leave caller-owned connection lifecycle and transaction configuration under application control.
• Add runtime resource-ownership coverage and PostgreSQL commit/rollback integration tests.
• Document ownership, transaction control, exception behavior, and synchronous execution.

Scope and non-goals

• Generated classes continue to depend only on QueryExecutor.
• DataSource operations continue acquiring and closing one connection per operation.
• Caller-owned connections are never closed, committed, rolled back, or reconfigured by sqlcj.
• This does not add transaction callbacks, savepoints, retries, pooling, framework adapters, asynchronous APIs, caching, tracing, metrics, or timeouts.