Enable bound parameters for PostgreSQL

[josetduarte]

Summary

Enable bound parameters by default for PostgreSQL/psycopg2 through the driver-specific PostgresPsycoCompiler, using %s placeholders. Generic PostgreSQL and JDBC compilers remain inline.

• Preserve parameters through SELECT, COUNT, INSERT, UPDATE and DELETE compilation and execution.
• Bind supported scalar values, IDs, references, pattern matching and CASE branches, while retaining the legacy encoding path for complex values.
• Reuse upstream Unicode conversion for text values and patterns, and emit positional parameters in SQL order.
• Preserve INSERT RETURNING behavior in both the compiler and legacy fallback paths, including renamed identifiers containing percent signs.
• Include bound parameter values in generated query-cache keys without changing explicit keys or unparameterized query keys.
• Escape literal percent signs in SQL independently from driver placeholders and parameter values.

Upstream integration

Merged upstream master without rewriting the existing PR history. Kept the upstream Unicode compatibility fix alongside the PR's ID and reference adaptation.

Regression coverage

Focused cases cover cache key compatibility and parameter isolation, composed LIKE/ILIKE/contains expressions, Unicode and NULL patterns, typed references, and INSERT behavior with compiler fallback, disabled compilation, empty rows, composite keys, renamed IDs and JDBC. The affected modules also run against an isolated PostgreSQL 16 database.

Scope

This change targets the existing PostgreSQL/psycopg2 parametrization work. New JSON/GIS operations and parameterization of additional drivers remain outside this PR.

Known upstream issue

The existing PostgreSQL recursive CTE fixture (tests.sql.TestSubselect.testCTE) uses a double-quoted space as a SQL string literal and raises UndefinedColumn. The same failure occurs on unchanged upstream dcf76747; this unrelated fixture is left outside the scope of this PR.

[leonelcamara]

@mdipierro this looks very good.

@josetduarte when/if this is merged a nice follow up would be to add the json and geo functions, so postgres can be completely modernized to the new way of doing things in pydal.

[josetduarte]

@mdipierro can you check this please?