gh-152157: Reject empty fraction before timezone in C fromisoformat

[tonghuaroot]

Fixes gh-152157

datetime.fromisoformat() and time.fromisoformat() accepted, in the C accelerator, a
decimal separator (. or ,) followed by zero fractional digits when a timezone
designator (+/-/Z) came next, e.g. '2020-01-01T12:34:56.+05:00' or '12:34:56.Z'.
The pure-Python implementation already raised ValueError for these. ISO 8601 §4.2.2.4 and
RFC 3339 §5.6 require at least one digit after the decimal sign, so the C side was the
lenient/incorrect one.

Divergence (before this PR)

Input	C accelerator	Pure-Python
'2020-01-01T12:34:56.+05:00'	parses, microsecond=0	ValueError
'2020-01-01T12:34:56.Z'	parses, microsecond=0	ValueError
'2020-01-01T12:34:56,+05:00'	parses, microsecond=0	ValueError
'12:34:56.+05:00'	parses, microsecond=0	ValueError
'12:34:56,+05:00'	parses, microsecond=0	ValueError
'12:34:56.Z'	parses, microsecond=0	ValueError

After this PR both implementations raise ValueError for all of the above, and all
previously-accepted valid strings (.5, .123456, comma fractions, no-fraction +offset,
Z) parse identically on both.

Fix

In parse_hh_mm_ss_ff() the decimal-separator case is now handled before the generic
end-of-substring check, so a separator with no following digit is rejected instead of being
treated as trailing content. The standalone trailing separator ('12:34:56.') remains
rejected. No change to the valid-fraction or no-fraction paths.

Note for reviewers

The spec requires ≥1 digit after the decimal sign, and the C implementation already rejects
a standalone trailing separator, so this PR fixes C to reject. The alternative direction
(making pure-Python lenient) is possible but contradicts both the spec and C's own
end-of-string behavior; happy to flip the approach if you'd rather standardize on lenient.

Tests

Added the four empty-fraction-before-tz inputs (offset, negative offset, Z, comma) to the
datetime and time fromisoformat failure tests, which run against both the C and
pure-Python implementations. Positive parity (valid fractions, comma fractions, and
no-fraction-with-offset) is already covered by the existing *_examples tests, which also
run on both implementations.

./python.exe -m test test_datetime passes (both impls), with no refleaks for the touched
tests.

[miss-islington-app]

Thanks @tonghuaroot for the PR, and @StanFromIreland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @tonghuaroot and @StanFromIreland, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 112c69a0514902af2d2f7d0503de6690ca59a10f 3.14

[bedevere-app]

GH-152761 is a backport of this pull request to the 3.15 branch.

[miss-islington-app]

Sorry, @tonghuaroot and @StanFromIreland, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 112c69a0514902af2d2f7d0503de6690ca59a10f 3.13

[StanFromIreland]

@tonghuaroot can you please do the backports?

[bedevere-app]

GH-152765 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-152766 is a backport of this pull request to the 3.13 branch.

[tonghuaroot]

Done — opened #152765 for 3.14 and #152766 for 3.13 (the 3.13 accelerator lacked the i < 2 decimal-on-hour check, so that branch only gets the empty-fraction rejection). Both build cleanly and test_datetime passes locally.

[StanFromIreland]

We need to backport #152061 first, can you do those please?