fix: accept the ten-byte S7 clock reply and emit it from the server

[gijzelaerr]

Fixes #925.

parse_get_clock_response only accepted exactly eight data bytes, while the S7 clock data (native Snap7 TResDataGetTime: Rsvd, HiYear, Time[8]) is ten bytes, as is the data the library sends in build_set_clock_request. A native server or PLC reply was therefore rejected.

• The parser accepts the ten-byte form (reserved, century, year..second, milliseconds/weekday), validates the BCD digits and milliseconds, and maps the two-digit year as 1990-2089. The eight-byte form is still tolerated.
• The bundled server now answers with the ten-byte form.
• New tests cover the ten-byte layout, milliseconds, and invalid milliseconds; the short-data message is updated.

This touches the same server lines as the weekday fix, so the two PRs will need a trivial rebase whichever lands second (the server here already uses Sunday=1).