feat: generate one repository per named query group

[omer-cengel]

Summary

Generated code now exposes one concrete repository per configured query group instead of one class per query, so an application constructs a single <Name>Repository per execution context and calls its typed query methods, rather than instantiating a separate type for every query.

Changes

• Each sql configuration entry requires a Java-safe name; an entry named Author generates AuthorRepository.
• All queries of an entry are analyzed first and passed to Java generation as an explicit query group, so grouping is never inferred from file paths or tables.
• Each repository is a final class with one QueryExecutor field, one constructor, and one public method per named query in declared order, preserving parameter types, parameter order, selected-column order, and JDBC binding order.
• Query-specific result records and row mappers are nested inside the repository.
• Per-query generated classes are removed; there is no compatibility mode.
• Query-name and method collisions are checked per repository and rejected before any file is written, including two queries whose nested result types differ only by case. Two repositories may reuse the same query name, and repository file collisions remain global within one output package.
• The external Maven sample, release verification script, README, and configuration, query, PostgreSQL, and quickstart guides use the repository API.

Scope and non-goals

• No generated repository interfaces, implementation suffixes, annotations, scanning, proxies, service locators, or repository factory.
• No automatic grouping by table or filename and no inferred CRUD methods beyond the named SQL.
• No new SQL constructs, types, transaction helpers, or runtime API changes; both existing JdbcQueryExecutor construction paths run the same generated repository.
• Result types and cardinality behavior (:one, :many, :exec) are unchanged.