Support ISO-8601 expanded years in XML dates (fix panic on dates outside 0000-9999)

[gaoflow]

Date::to_xml_format panics on any date whose year falls outside 0000-9999.
Binary plists store dates as an f64 offset from the 2001 epoch, so such dates are
valid and round-trip fine through Apple's tools; the common "read a binary plist,
re-serialize as XML" path then aborts the process on a file plutil considers OK.

Repro (year 11476, plutil -lint reports OK):

let value = Value::from_reader(far_future_bplist)?; // reads fine
value.to_writer_xml(&mut out)?;                      // panics: "overflow adding duration to date"

There are two panic sites, both in the date <-> string layer:

• year >= 10000 (or < -9999): SystemTime -> OffsetDateTime overflows inside time.
• year 0000 down to -9999: time's RFC 3339 formatter rejects the year, and the
  .unwrap() on that Err panics.

They surface through every path that stringifies a Date: to_writer_xml /
to_file_xml, impl Debug for Date, and serde Serialize. The read side is the
mirror image: from_xml_format can't parse the expanded-year strings Apple writes
(11476-..., -29719-...), so a plist written by plutil can't be read back.

The fix keeps time's RFC 3339 for years 0000-9999 (output unchanged, including
sub-second precision) and handles the expanded range directly, byte-for-byte with
plutil:

• 11476-08-15T05:20:00Z, 33658-09-27T01:46:40Z
• -29719-04-05T22:13:20Z, -001-11-28T00:00:00Z (Apple pads the year %04d-style,
  so year -1 is -001, not -0001)

time can't produce this itself: even with large-dates its formatter emits
+11476 / -0001 rather than Apple's 11476 / -001, and its year range
(±999999) is narrower than the plist date domain (plutil prints year 285,200,616
for a large enough f64). So the expanded range uses a small proleptic-Gregorian
conversion. Out-of-range or malformed strings return InvalidXmlDate instead of
panicking.

New tests cover the 9999/10000 boundary, far past/future and negative years against
plutil's output, the read/write round-trip, the Debug path, and rejection of
invalid dates. cargo test --all-features passes.

This lines up with the Apple-compatibility goal in #118.

One thing left out on purpose: for in-range dates rust-plist still emits sub-second
precision (e.g. ...00.5Z) where plutil truncates to whole seconds (related to
#13). I kept in-range output unchanged to avoid touching round-trip behaviour, but
can fold that in if you'd like.