strip L suffix for oversized hex literals in createNumber

[alhudz]

Repro: NumberUtils.createNumber("0xFFFFFFFFFFFFFFFFL") throws NumberFormatException: For input string: "FFFFFFL".
Expected: a BigInteger of 0xFFFFFFFFFFFFFFFF, the same result as createNumber("0xFFFFFFFFFFFFFFFF") (no suffix) and the decimal path createNumber("9223372036854775808L").
Cause: the hex branch that is too large for a Long calls createBigInteger(str) with the L/l type suffix still attached. createBigInteger strips only the radix prefix and then runs new BigInteger(substring, 16), so the trailing L reaches the hex parser and is rejected. The decimal branch already drops the suffix before its BigInteger fallback, which is why only the hex form throws.
Fix: drop the trailing type char before the createBigInteger fallback when the literal carries one, so an over-long hex literal with a suffix parses the same as the unsuffixed form.

Covers the 0x/0X/# prefixes, signed and unsigned. Regression assertions added to NumberUtilsTest.testCreateNumber; they fail with NumberFormatException before the change and pass after.

• 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.

[sarankumarbaskar]

This looks consistent with the decimal suffix path, and the added tests fail without the production change. One small suggestion: since the description mentions signed forms and nearby LANG-1645 tests cover +0x..., it would give wider coverage to add a +0xFFFFFFFFFFFFFFFFL assertion as well.

assertEquals(new BigInteger("+FFFFFFFFFFFFFFFF", 16),
        NumberUtils.createNumber("+0xFFFFFFFFFFFFFFFFL"));