Support general expression operands in comparisons

[alexeichhorn]

Context

dbkit supports several comparison forms but does not have one coherent expression-operand contract.

Current examples:

column.lt(computed_expression);       // supported
(column + 1).lt(other_column + 1);    // rejected
column.eq_col(other_column);          // supported
column.eq(computed_expression);       // rejected
column.between(low_expr, high_expr);  // rejected
column.like(pattern_expr);            // rejected

PostgreSQL accepts expressions in all these operand positions. The rejected forms are capability gaps rather than runtime correctness bugs.

Desired direction

• Design one shared comparison-operand abstraction for Rust values, columns, and computed expressions.
• Preserve base-type compatibility checks.
• Propagate nullability from every participating operand.
• Cover equality, inequality, ordering, BETWEEN, and pattern operations consistently.
• Preserve explicit helpers such as _col where they improve clarity.
• Avoid isolated overloads that make only one operator more permissive.

This should be designed after or together with #45, which tracks incorrect base-type checking for ordered comparison values.