Fix parse position for hour-only timezone offsets

[mehuljariwala]

Purpose

Keep ParsePosition within the consumed input when parsing an hour-only ISO 8601 timezone offset.

Description

The parser pads +01 to +0100 for timezone lookup, then counts the padded length as consumed input. As a result, successfully parsing 2018-06-25T00:00:00+01 advances the position two characters past the end of the string.

Count the original timezone text before padding it. Tests cover positive, negative, and zero hour-only offsets, full offsets with and without a colon, unchanged parsed instants, and a nonzero starting parse position. Both new tests fail before the fix. This changes position accounting without changing the accepted timezone formats or resulting dates.

Checklist

• Google Java formatting checked with Spotless.
• Added regression tests using Truth and JUnit 4.
• mvn clean verify javadoc:jar passes on JDK 17, including all eight reactor modules.
• No new public API or argument-validation contract.

The Surefire reports contain 4,854 tests, no failures or errors, and 19 skips. The new legacy-Date test uses a method-scoped JavaUtilDate lint suppression, following the neighboring tests, after JDK 21 CI flagged the Date API comparisons. Prepared with OpenAI Codex assistance; tests and build verification were executed locally.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Marcono1234]

Did you intentionally close this PR, or was it accidental when you deleted your fork?

[Marcono1234]

For future reference: This PR seems to fix a real bug. However, the bug probably has no noticeable effect on users because ISO8601Utils is internal and the only internal call to parse ignores the parse end offset (which probably means it also does not detect malformed trailing data? but that is a different topic).
Though fixing this would probably be good nonetheless to avoid running into this issue in the future in case the usage of ISO8601Utils is changed within the Gson code.

Edit: Created #3131 now to include the fix from this PR here.