Parse colon-separated dates instead of misreading them as times (#1447) - #1626

Fixes #1447.

parser.parse mishandled colon-separated dates whose first component cannot be an hour:

>>> parse('2025:12:05')
ParserError: hour must be in 0..23: 2025:12:05
>>> parse('2025:12:05 19:09:37')
datetime(2026, 10, 22, 19, 9, 37)   # the date is silently lost

The : branch of _parse_numeric_token unconditionally treated an AA:BB:CC triple as HH:MM:SS. This adds a branch ahead of it: when the first component is larger than 23 (so it cannot be an hour), all three components are plain integers, and no date has been collected yet, the triple is appended to ymd like the -///.-separated date branches, so resolve_ymd applies the usual year/month/day heuristics (including dayfirst/yearfirst).

>>> parse('2025:12:05')
datetime(2025, 12, 5)
>>> parse('2025:12:05 19:09:37')
datetime(2025, 12, 5, 19, 9, 37)
>>> parse('19:09:37 2025:12:05')
datetime(2025, 12, 5, 19, 9, 37)
>>> parse('2025:13:05')
ParserError: month must be in 1..12: 2025:13:05

Genuine times are untouched (a first component of 0-23 still takes the time branch, so ambiguous strings like 12:05:06 parse exactly as before), as are all other separators.

Tests: 6 new cases in tests/test_parser.py. tests/test_parser.py fully passes (237 passed, 14 xfailed). Full suite: 5049 passed; the only failures are 3 pre-existing tzdata-environment failures (test_tz.py::test_gettz_link[tzpath-...], test_tzfile.py::test_gettz_local_abbreviation_without_time_zone_data, test_tzpath_data.py::test_dst_matches_tzdata_zi[tzpath]), which fail identically on unmodified master in this environment and are unrelated to the parser.