Improve strict mode and error collecting

In #186 we added a strict/lenient mode for the parser. This is a good first step for making things more configurable, but it isn't great overall. While implementing I also noticed that "strict" mode isn't actually that strict. There are various length checks being skipped and the converted values are not actually validated.

One possible approach would be to have `icalSet` in the design data be the lenient set, and add a `strictIcalSet` that does additional checks, including all necessary length and data type checks. The lenient one would accept a date as date-time and vice versa. You'd then be able to pass a specific set to `ICAL.parse`. Another approach might just be a `strict` flag on `ICAL.parse`, that would select the set automatically.

Then again, some folks might want lenient mode, but not as lenient that it would accept all types. Another idea might be an error collector that would have a function that would be able to resolve certain errors. One provided resolver might be one that swaps date/date-time accordingly.

Start by tracing the existing icalSet configuration and the ICAL.parse entry point, then identify where length checks and converted-value validation are skipped. Compare the proposed strictIcalSet, strict-flag, and error-collector approaches. Done requires an agreed behavior for strict and lenient parsing, including how date/date-time mismatches and resolvers should be handled.

Written by the indexing model from the issue text.