feat(analysis): type BETWEEN and NOT BETWEEN range bound placeholders

[omer-cengel]

Summary

Range predicates on a direct column now produce typed method parameters. Before this change, BETWEEN $1 AND $2 was rejected as an unanalyzed placeholder location, and a named bound such as :lo could reach the executable SQL unbound. Each $N bound of <column> BETWEEN ... AND ... and NOT BETWEEN now takes the tested column's type and binds in textual order.

Changes

• BETWEEN and NOT BETWEEN on a direct, optionally qualified column in a SELECT, UPDATE, or DELETE WHERE clause bind each $N bound typed from that column. The start bound binds before the end bound, whatever their placeholder indexes are.
• A placeholder bound next to a literal bound is typed the same way. A range with only literal bounds binds nothing and reaches the database as written.
• An unknown tested column is rejected by column resolution. A named bound such as id BETWEEN :lo AND :hi fails with the named-parameter diagnostic.
• A placeholder as the tested value ($1 BETWEEN id AND id) or inside a computed bound (id BETWEEN $1 + 1 AND $2) is still rejected as an unanalyzed placeholder location.
• Parameter names come from the column through the existing naming rule, so code BETWEEN $1 AND $2 generates code1 and code2.
• Analyzer tests cover these cases. A PostgreSQL integration test runs a generated BETWEEN read and a NOT BETWEEN read with out-of-order placeholder indexes.
• The query documentation describes the new forms, how bounds are typed and ordered, and the nearby forms that are rejected or not analyzed.

Scope and non-goals

• The generator, runtime, and query model are unchanged.
• BETWEEN SYMMETRIC, column-type restrictions on range bounds, and column resolution for a range with no placeholder bound are not included.
• No dedicated diagnostics for a placeholder as the tested value or inside a computed bound.