Case insensitive Constraints via ignoreCase method per Constraint subtype that can support it

[njr-11]

Option 2 for case insensitive Constraints:
Add .ignoreCase() to specific subtypes of Constraint that are capable of case insensitive comparisons when operating on String values. This includes Like, NotLike, EqualTo, NotEqualTo, Between, NotBetween, and the various GT/LT/GTE/LTE constraints. If a user ever invokes ignoreCase() on a constraint that has a non-String value, it will raise UnsupportedOperationException.
Provide an isCaseSensitive() method for each of these same subtypes to determine if a Constraint performs case insensitive comparisons, defaulting it based on whether the value is a String (true for String and false for others). When it starts as true, an instance with false can be obtained by invoking ignoreCase().

Example usage:

List<Book> booksTitled(Constraint<String> title);

found = library.booksTitled(Constraint.equalTo("Developing with Jakarta Data").ignoreCase());

We should choose between this PR or #1005 (or if someone thinks of another way) for case-insensitive constraints

[njr-11]

Now that TextExpression.upper/lower went in and provided an alternative to ignoreCase for Restriction, we had a discussion on today's Jakarta Data call about how to cover case insensitive for the pattern of Constraint parameters being supplied to repository methods. The other solution under #1005 was preferred by all 5 participants on the call instead of the solution under this PR, so at this time, I am not planning to resolve the merge conflicts within this PR.

[gavinking]

Sorry I could not make it to the call today, I had an exam at the same time.

I am not planning to resolve the merge conflicts within this PR.

I'm not particularly a fan of either approach, so I agree that we don't need to move forward with this one, which adds quite a lot of complexity for something of really quite marginal value.

Seems to me that the most parsimonious thing to do — supposing we need to even do anything at this stage — would be to add the concept of case-insensitivity back to Like, where it is quite commonly used, and just forget about the other comparisons. That option:

• adds only a teensy bit of incremental complexity, and no new API concepts,
• covers upward of 95% of usage patterns, and
• is highly discoverable for users.

Note that for the cases which are not covered by Like, users have the escape hatch of writing the query in JDQL. We don't need to dupe every feature of JDQL in @Find methods.

[njr-11]

Closing this in favor of #1005