feat: add Query Builder whereColumn methods

[memleakd]

Description

This PR proposes adding whereColumn() and orWhereColumn() to the Query Builder for comparing one column to another column without dropping down to raw SQL.

This improves Query Builder DX for a common SQL pattern and reduces the need for manually written raw conditions like where('created_at < updated_at'). It also keeps the comparison inside the framework’s identifier-protection flow instead of asking users to handle that manually.

$builder->whereColumn('created_at', 'updated_at');
// WHERE "created_at" = "updated_at"

$builder->whereColumn('updated_at >', 'created_at');
// WHERE "updated_at" > "created_at"

$builder->orWhereColumn('published_at <=', 'expires_at');
// OR "published_at" <= "expires_at"

This is useful for common column-comparison queries while keeping the existing Query Builder behavior around identifier protection. The API follows the existing Query Builder convention of placing the operator in the first argument. If no operator is provided, = is used. Column names are protected by default, and $escape = false remains available for advanced cases such as SQL functions.

Supported operators are =, !=, <>, <, >, <=, and >=. Empty column names, unsupported operators, or ambiguous calls like whereColumn('created_at', '>=') throw an InvalidArgumentException.

Implementation note

This PR keeps the operator parsing local to whereColumn() so it does not change the long-standing behavior of where() / having(). There may be a future internal refactor opportunity to share operator parsing more broadly, but that is intentionally out of scope here to keep this PR focused and low-risk.

Changes

• Added whereColumn() and orWhereColumn() to BaseBuilder.
• Added Model PHPDoc forwarding entries.
• Added user guide docs, class reference entries, and changelog entry.
• Added tests for default operator, explicit operators, OR, grouping, alias/prefix protection, unescaped expressions, invalid columns, invalid operators, and ambiguous operator-as-second-column usage.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

I like the idea, but I'm not particularly a fan of the implementation. And that's because of the $operator. The existing builder style puts the operator in the first argument, and if we create precedence here, some people may expect this is how it works everywhere.

To be fair, if I were designing this from scratch, I would probably prefer a separate operator parameter. But that is not the convention CodeIgniter has established, and I do not think this is the right place to introduce that inconsistency.

Also, in the current implementation, there is no way to distinguish "second column" from "operator with missing third argument", so whereColumn('created_at', '>=') becomes WHERE "created_at" = ">=".

[memleakd]

That makes sense. I agree that even if a separate operator parameter is nice in isolation, it is inconsistent with existing convention.

I’ll refactor this to parse the operator from the first argument, e.g. whereColumn('updated_at >', 'created_at'), default to =, and reject ambiguous cases like whereColumn('created_at', '>=').

[memleakd]

Thanks for the review and direction.

I pushed a refactor that aligns the API with the existing Query Builder convention and also updated the PR body.

[datamweb]

Thank you for refactoring the code! I find the changes very useful and appreciate your effort.