Update the proposal for UTCClock to reflect the discussion surrounding it

[phausler]

There were a few places where the examples left some lack of clarity of the proposed clock usages and behaviors. This refines those examples to a more concrete use case that avoids any confusion about the role associated with UTCClock and additionally clarifies the stance on the placement/homing of Date, the definition of timezones and the relationship to UTC, the naming of systemEpoch and finally a reflection of the proposal discussion out lasting the cutoff of 6.2.

[itingliu]

Suggested change

The structure of the `UTCClock` is trivially sendable since it houses no specific state and has the defined typealias of its `Instant` as `Date`. The minimum feasible resolution of `Date` is 1 nanosecond. The sleep method may respond to host system time adjustments; e.g. if a system has it's time changed manually or if the system adjusts the time drift via ntp updates so the sleep method, unlike ContinuousClock, is not strictly monotonic. However, since UTC itself is the root definition of timezones[^timezones] there is no daylight savings time adjustment; any calculation for accounting to DST must be done before hand by interacting with the Calendar and deriving a Date accordingly.

The structure of the `UTCClock` is trivially sendable since it houses no specific state and has the defined typealias of its `Instant` as `Date`. The minimum feasible resolution of `Date` is 1 nanosecond. The sleep method may respond to host system time adjustments; e.g. if a system has its time changed manually or if the system adjusts the time drift via ntp updates so the sleep method, unlike ContinuousClock, is not strictly monotonic. However, since UTC itself is the root definition of timezones[^timezones] there is no daylight savings time adjustment; any calculation for accounting to DST must be done before hand by interacting with the Calendar and deriving a Date accordingly.

[itingliu]

Is this part an outdated version of the previous? I don't see a duration(to:includingLeapSeconds:). Should it just be func duration(to other: Date)?

And the functionality to get the leap seconds between two would be covered by public static func leapSeconds(from start: Date, to end: Date) -> Duration below

[itingliu]

typo:

Suggested change

It was considered to add a new `Instant` type instead of depending on `Date` however this was rejected since it would mean re-implementing a vast swath of the supporting APIs for `Calendar` and such. The advantage of this is minimal and does not counteract the additional API complexity. This consideration did delve into the idea of moving Date to a lower scope and also changing it's storage, however due to the complexity of that; it is considered a non-goal of this proposal and squarely in the out of scope territory. The beneifit of scheduling and appropriate calculations with regards to leap seconds are valueable on their own and distinctly seperable tasks to any sort of re-orgnaization of Date et al.

It was considered to add a new `Instant` type instead of depending on `Date` however this was rejected since it would mean re-implementing a vast swath of the supporting APIs for `Calendar` and such. The advantage of this is minimal and does not counteract the additional API complexity. This consideration did delve into the idea of moving Date to a lower scope and also changing its storage, however due to the complexity of that; it is considered a non-goal of this proposal and squarely in the out of scope territory. The benefit of scheduling and appropriate calculations with regards to leap seconds are valuable on their own and distinctly separable tasks to any sort of re-organization of Date et al.

hit the approval by mistake. There are a few nits

[itingliu]

@swift-ci please test