feat: add Query Builder likeAny helpers

[memleakd]

Description

This PR proposes adding likeAny() and orLikeAny() to Query Builder.

The goal is to make a very common search pattern easier to write: search one value across a few columns, while keeping those LIKE conditions grouped safely.

$builder->where('active', 1)->likeAny(['title', 'body', 'summary'], $search);

Instead of writing the group manually, this produces the expected shape:

WHERE active = 1
AND (
    title LIKE '%term%'
    OR body LIKE '%term%'
    OR summary LIKE '%term%'
)

This keeps the existing like() behavior unchanged. Passing an associative array to like() still creates multiple LIKE clauses joined with AND; likeAny() is only for the "same value across any of these fields" case.

Internally this reuses the existing LIKE handling, so binds, escaping, wildcard placement, RawSql, and case-insensitive search behave the same way as like().

Tests cover grouped SQL generation, binds, invalid field lists, RawSql, case-insensitive search, and live database behavior.

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

[datamweb]

Suggested change

	}
	}
	if (! preg_match('/^[A-Za-z0-9_\.]+$/', $field)) {
	throw new InvalidArgumentException(sprintf('Invalid field name "%s". Only alphanumeric characters, underscore, and dot are allowed.', $field));
	}

I suggested the strict field-name check because these values are used as SQL identifiers, not regular data values, so is_string() alone doesn’t really guarantee they’re safe.

Using a small allowlist here feels like a nice extra guardrail before the query is built.

What do you think?

[memleakd]

Thanks for taking a look.

I don't think we should add this validation here. It would make this method more restrictive than the rest of Query Builder, and identifier protection should stay in the existing escaping/compiler flow.

I agree with the safety concern though, so I think a docs note about not passing user input directly as field names would be a better fit.