Perform locale-sensitive string comparison in BooleanConverter

[basil]

Extends #366 (so is not subject to @garydgregory's veto, which applied to a different hunk of code), but also incorporates a suggested enhancement from @ppkarwasz (adding full locale support to custom boolean types). The new test fails before the changes to src/main to do locale-sensitive string comparison and passes after them.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best-practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[ppkarwasz]

Hi @basil,

Thanks for the PR! 💯 It looks good to me, but I added some remarks below.

For context (and to anticipate possible feedback from other reviewers): the current approach of using toLowerCase(Locale.ROOT) to compare custom true/false strings doesn’t work well in an internationalized context.

On the other hand, allowing custom strings only in English doesn’t seem very useful, since the default values already cover nearly all meaningful alternatives for “true” and “false.”

Given that, I’d suggest we either:

• Accept this PR, which correctly handles case-insensitive and locale-dependent Unicode comparisons, or
• Remove the ability to supply custom strings to BooleanConverter altogether.

[ppkarwasz]

LGTM, but let's wait until the discussion on dev@commons is over before merging.