[caglarpir]

Stacked on #910; review the last commit.

Cameras without a clock write placeholder dates: some FLIR thermal
cameras 0001:01:01 00:00:00, which #879 rejects as having no Unix time,
and others a date in 1904 or 1969:12:31 19:00:00 (Unix time 0 in a time
zone west of UTC). With a time zone offset, as when OffsetTimeOriginal
is +01:00, 0001:01:01 00:00:00 does have a Unix time, before year 1 in
UTC: the image passed, and writing its capture time to the description
crashed the whole run with "ValueError: year 0 is out of range". The
dates in 1904 and 1969 were taken as capture times: geotagged from a
GPX, such an image was reported as decades outside the track.

The EXIF, XMP and ExifTool readers now pass over a capture time before
1970, in the GPS date and in each EXIF date tag, so that the next date
tag is read: DateTimeOriginal, then CreateDate, then ModifyDate. An
image whose date tags all hold such dates has no capture time, and is
reported as a geotagging error, "Unable to extract timestamp from the
image". A capture time that cannot be written as a date no longer
crashes the run either: it fails the image's validation.

Checked process on 17,090 sample images from many camera models, with
the default sources and with exiftool_runtime: only three change. A
phone that writes a GPS date in 1961 beside the right DateTimeOriginal
is now dated by the latter, 47 years later. The two FLIR images dated
0001:01:01 are still reported as having no capture time, without the
date in the message. Given an OffsetTimeOriginal of +01:00, one of them
is reported the same way, where the run crashed.

Unit and integration tests, doctests, mypy --python-version 3.9, ruff check, ruff format --check and usort diff are clean.