Update a re-imported event rather than skipping it

Contacts and calendars disagreed on a re-import: a vCard or LDIF entry
whose identity a book already held overwrote the card there (#242, #274),
while an event whose UID a calendar held was counted and thrown away
(#222). The asymmetry was never decided -- it was where each half stopped.

Decided on #279: calendars update too, with two properties held back.
`participants` carries every attendee's accepted/declined and
`recurrenceOverrides` holds every "just this Wednesday" edit made here.
Both are decisions taken after the file was written, and a file that
mentions them at all describes them as they were at export, so writing
either one over would destroy work silently and return no error. A
corrected export now fixes the time, the title and the location, and
leaves who said yes alone. `uid` is held back with them: it is what the
two were matched on, so it is already equal.

The scan returns uid -> id rather than a set of UIDs, since updating
needs something to address, and creates and updates now share one
`maxObjectsInSet` budget the way contacts' `writeCards` does -- 300 new
and 300 changed batched separately would be two calls of 300, neither
over a ceiling of 500 and both refused. Counts become created/updated,
reported as the contacts import reports them.

Still no scheduling messages, on an update as much as on a create. That
is a real cost -- an event a re-import moves is moved here and nowhere
else -- and it is the lesser one: an import is not the place to start
mailing a room full of people who never asked for it.

Driven against the mock end to end: a second file with the same UID
updated the event in place, took the file's title, start and location,
and left an accepted RSVP and a per-occurrence override untouched even
though the file carried participants of its own.

FEATURES.md

@@ -546,6 +546,24 @@ nothing for anybody else.
 - **iCal import** through `CalendarEvent/parse` (a file of any number of
   events), from the calendar's own menu, into that calendar. The events are
   filed rather than scheduled: no invitations go out to anyone named in them.
+- **Re-importing updates rather than duplicates**, as a contacts import does.
+  An event is recognised by its UID, per calendar, and what the file carries
+  wins -- so a corrected export corrects what the first attempt got wrong.
+
+  Two things are deliberately left alone: **who accepted**, and **edits to a
+  single occurrence**. Both are answers and decisions taken here after the file
+  was written, and a file that mentions them at all describes them as they were
+  at export, so writing either one over would throw away work silently and
+  return no error anywhere. A corrected export therefore fixes the time, the
+  title and the location, and leaves the RSVPs and the "just this Wednesday"
+  changes where they are.
+
+  The cost runs both ways and is worth knowing. An attendee added at the source
+  since the last import does not arrive, because nothing here can tell that
+  apart from an answer given in ihasmail. And an import still sends no
+  scheduling messages, so an event a re-import moves is moved *here* --
+  everybody else's copy still says the old time until whoever is organising
+  sends the update from the event itself.
 - **Subscribed calendars** by URL — a timetable, a rota, a public holiday list.
   Added in Settings › Calendar & contacts, read-only, and shown beside your own
   with their own colour.