Don't mangle a vCard timestamp given in the extended format; fixes #1028

[mkmelin]

The vcard4 design set aliases the timestamp value type to iCalendar's date-time, whose fromICAL/toICAL insert and remove the separators at fixed offsets because iCalendar only ever uses the basic format. RFC 6350 allows only the basic format for a timestamp as well, but the extended format is widely used in the wild, and slicing it at those offsets produced garbage: parsing REV:1995-10-31T22:27:10Z gave the jCal value 1995--1-0-T1T:22::2, stringified back as REV:1995-10-T1T22:2.

Delegate to the date-and-or-time conversions, which probe the value length instead of assuming offsets, so both formats are read and a UTC offset survives. Output stays in the basic format. decorate/undecorate are kept as they were, so getFirstValue() on REV still returns an ICAL.Time.

[kewisch]

There is a lenient switch somewhere that should be used for more lenient parsing. The idea is that if you prefer strict validation (e.g. because you want to verify if it is correct) you can use the default, but if you want to accept usage in the wild then lenient mode is for you.

It sounds like that would be useful here?

I think the other issue, probably outside of this PR, is that there isn't good validation in date parsing (I think back then done in the name of performance), which leads to the 1995--1-0-... problem. It should be rejected rather than producing incorrect results.

[mkmelin]

Good call. The extended format is now only accepted when design.strict is false. Looks like we need to set that in Thunderbird though (for address book).

I can open another issue for rejecting malformed date/time values