Accept ISO 8601 (with timezone) for --video_start_time

[ptpt]

Summary

Addresses part of #819 (GoPro MAX timestamping). The --video_start_time option only accepted the proprietary YYYY_MM_DD_HH_MM_SS_sss format, which is always interpreted as UTC. This left no clean way to correct timestamps for cameras whose RTC has no timezone and therefore records local time (e.g. GoPro MAX).

This PR makes --video_start_time also accept ISO 8601, which carries timezone information:

Input	Interpreted as	Result (UTC)
2020_12_28_13_36_36_508 (legacy)	UTC	13:36:36Z
2020-12-28T13:36:36.508Z	UTC	13:36:36Z
2020-12-28T13:36:36.508+01:00	offset as given	12:36:36Z
2020-12-28T13:36:36.508 (naive)	system local time	depends on host tz

• The legacy format is unchanged (still UTC).
• An ISO 8601 value with an explicit offset (or Z) is honored.
• A naive ISO 8601 value is interpreted in the system local timezone, so a wall-clock time copied straight off a local-time camera lands at the right instant.

Implementation

A new _parse_video_start_time() helper in sample_video.py tries the legacy format first, then falls back to datetime.fromisoformat (with a Z→+00:00 shim for Python 3.9/3.10 compatibility) and normalizes to UTC via astimezone. The CLI help text is updated accordingly.

Notes

• Behavior is documented and covered by doctests on the helper.
• A naive ISO value is host-timezone dependent by design — worth keeping in mind for CI/automated pipelines.
• This does not address the other items in Video Timestamping Bugs with GoPro MAX #819 (the GPMF-vs-RTC discrepancy, the GPX fallback for empty-GPMF videos). Happy to follow up on the GPX fallback separately.

Test plan

• Doctests pass (pytest --doctest-modules mapillary_tools/sample_video.py), including under TZ=US/Pacific
• Full unit suite: 616 passed, 18 skipped, 1 xfailed
• mypy and ruff clean