Stop narrowing BigInteger and BigDecimal in StringLocaleConverter

[rootvector2]

StringLocaleConverter.parse formatted BigInteger via ((Number) value).longValue() and BigDecimal via doubleValue(), so a value wider than 64 bits was narrowed before formatting and came back silently wrong (new BigInteger("99999999999999999999") formatted to 7,766,279,631,452,241,919); DecimalFormat.format(Object) handles BigInteger/BigDecimal with full magnitude natively, so I format those two types directly and keep the long/double path for the primitive wrappers. Found while auditing the locale converters against the magnitude handling in BigIntegerLocaleConverter/BigDecimalLocaleConverter.

• 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. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hi @rootvector2
Thank you for the PR, merged; please port to the 1.X branch.