Preserve magnitude in BigInteger and BigDecimal locale converters

[rootvector2]

BigIntegerLocaleConverter and BigDecimalLocaleConverter derive their result from the Long/Double that DecimalLocaleConverter.parse returns because setParseBigDecimal is never enabled, so a value past long/double range comes back silently wrong (9999999999999999999 becomes 9223372036854775807 for BigInteger and 1.0E+19 for BigDecimal); enabling setParseBigDecimal only for those two converters via an isParseBigDecimal() hook keeps the parse lossless while the narrowing Byte/Short/Integer/Long/Float/Double converters (and DoubleLocaleConverter's (Double) cast) are untouched, found by comparing the locale converters with the non-locale BigInteger/BigDecimal converters that parse the string directly.

• 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. Which AI tool was used to create this pull request, and to what extent did it contribute?
• 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.

[garydgregory]

Thank you for the PR @rootvector2, merged 🚀
Would you please port to the 1.X branch?
TY!