feat: support case-insensitive query parameter matching

[olavloite]

Normalize bound parameter names case-insensitively against the parameter names parsed from the SQL statement. This allows using any case in database/sql named arguments (e.g. sql.Named('id', ...)) to match case-insensitive query parameters in the statement (e.g. @id).

Fixes #594

[gemini-code-assist]

Code Review

This pull request introduces case-insensitive matching for named parameters in Spanner statements, along with corresponding unit tests for both GoogleSQL and PostgreSQL dialects. The reviewer recommended checking for an exact match first before performing case-insensitive matching. This ensures determinism (since map iteration in Go is non-deterministic and could lead to incorrect matches if multiple casing variations exist) and improves performance by avoiding unnecessary loops and case-insensitive comparisons in the common case.

[olavloite]

Great feature to support case-insensitive query parameter matching.

However, I have one critical correctness recommendation:
Currently, the code iterates over namesToIndex and names using strings.EqualFold to find a match. If a query contains both @id and @ID (which are valid and distinct in GoogleSQL), and the user passes sql.Named(\"ID\", 1), the case-insensitive loop might match @id first (since map iteration order is randomized).

To fix this and avoid non-deterministic behavior, we should check for an exact match first before falling back to the case-insensitive search loop. Checking for an exact match first will also optimize the hot path for queries where the casing matches exactly, avoiding the (N \times M)$ comparison loop entirely.