ical-recurrence: apply a RANGE=THISANDFUTURE override to the instances it covers
Follows #41, which made a `RECURRENCE-ID` replace the instance it names. A `RANGE=THISANDFUTURE` override still only affected that one instance, so the instances after it kept the series' time and the series' duration.
Two commits: the first is red (four of its five tests fail), the second is the fix.
## What propagates
[§3.8.4.4](https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.4.4):
> The "RANGE" parameter is used to specify the effective range of recurrence instances from the instance specified by the "RECURRENCE-ID" property value. The value for the range parameter can only be "THISANDFUTURE" to indicate a range defined by the given recurrence instance and all subsequent instances. Subsequent instances are determined by their "RECURRENCE-ID" value and not their current scheduled start time. Subsequent instances defined in separate components are not impacted by the given recurrence instance. When the given recurrence instance is rescheduled, all subsequent instances are also rescheduled by the same time difference. [...]
> Similarly, if the duration of the given recurrence instance is modified, then all subsequence instances are also modified to have this same duration.
Two things propagate — the rescheduling and the duration — and one does not: an instance that has an override component of its own.
An instance's own start *is* its `RECURRENCE-ID` value, so the override that covers it is the last one naming an instance at or before it. Two overrides therefore do not compose: each measures its difference from the instance it names, not from where an earlier override left that instance.
## Exact, not nominal
The difference is an exact duration, matching what §3.8.5.1 already requires of a `DTEND` ("the same exact duration will apply to all the members of the generated recurrence set") and what `computeNewEnd` already does with it. For a zoned instance that is also what keeps the wall clock: two hours after 09:00 is 11:00 in whichever offset the day happens to be in, because `addExactDuration` resolves and unresolves through the time zone rather than adding to the local time. There is a test for exactly that, across the October 2022 Zurich transition.
This is the only part of the `RECURRENCE-ID` work with real arithmetic, so the difference is covered in each form it can take: an exact duration between two `DATE-TIME`s, the same across a daylight saving change, and a whole number of days between two `DATE`s.
## The component
Only the rescheduling and the duration are prescribed. The override's component comes along with them, because an `Occurrence` carries the component whose properties apply to it, and a producer that writes "this and future" with a changed `SUMMARY` means that for the range too. Say the word if you would rather a rescheduled instance kept the series' component and took only its timing from the override.
## Mismatched value types
A `RECURRENCE-ID`, the `DTSTART` of the component carrying it, and the instances of the series all have to share a value type. `ThisAndFutureMismatch` is a new **unfixable** error for input where they do not: there is no rescheduling to derive from a number of days and a time of day. This follows `StartEndMismatch`, which the same section's value-type requirement already made unfixable.
Every `.occ` and `.res` golden is still byte-identical.