Adding TZID to DTSTART within the VTIMEZONE block is invalid

Currently there is no way to avoid adding the TZID parameter when using `Props.SetDateTime`. if a timezone is specificed it's automatically added. This is great in most cases however it's invalid when applied to the `DTSTART` value when it's within a `VTIMEZONE` block.

> Within the "STANDARD" and "DAYLIGHT" sub-components, this property defines the effective start date and time for a time zone specification. This property is REQUIRED within each "STANDARD" and "DAYLIGHT" sub-components included in ["VTIMEZONE"](https://icalendar.org/iCalendar-RFC-5545/3-6-5-time-zone-component.html) calendar components and MUST be specified as a date with local time without the ["TZID"](https://icalendar.org/iCalendar-RFC-5545/3-8-3-1-time-zone-identifier.html) property parameter.

Ref: https://icalendar.org/iCalendar-RFC-5545/3-8-2-4-date-time-start.html

I've kicked a few ideas around this but in the end it's all a bunch of hacks and work arounds. I'd really hate to add a specific set of "SetDateTimeX" functions to `Props` and `Prop` but that may be the way to fix this. I'm open to suggestions and willing to submit the patch but just figured I'd post this first for discussion purposes.

Start by reading Props.SetDateTime and the related Prop APIs to understand how a timezone causes TZID to be added. Check how DTSTART is represented inside VTIMEZONE STANDARD and DAYLIGHT components, then determine an API that avoids TZID there without changing ordinary date-time output. Done means RFC-compliant VTIMEZONE DTSTART values and preserved behavior elsewhere.

Written by the indexing model from the issue text.