add versioning to preferences

[Cattn]

this allows for better caching, smarter event replacing & more!

A backend PR accompanies this. WITCodingClub/calendar-backend#666

[Cattn]

I'll merge this into the stack once the upstream work on #180 is done (on the backend mainly) and the backend PR is merged WITCodingClub/calendar-backend#666

[jaspermayone]

@Cattn I pushed some backend changes to WITCodingClub/calendar-backend#666 (4c49c559). The batch endpoint (POST /api/meeting_times/preferences) now returns a version field with the same token as GET /api/user/preferences/version.

Please use that field in this PR:

• When a batch response arrives, store its version with the cached data. Do not label the data with a version from a separate /user/preferences/version call.
• The reason is a race between the two requests. A batch request can read old data, then a save happens, then a version check returns the new token. The cache then holds old data under the new token, and it stays old until the next change.
• The server reads the version before the preferences. If a write happens between the two reads, the response has an old version with new data. The next five-minute check then sees a different token and reloads. This is safe.
• Keep the five-minute poll as it is. Only the source of the version on cached data changes.
• An older server does not send version. In that case, do not cache, as the "legacy servers" path does now.

Other backend changes, for your information: schema: 1 is removed, and the list of default constants now lives in PreferenceResolver.defaults. That list also adds UNI_CAL_ALL_DAY_REMINDERS, which was missing. Tokens change one time after the deploy, so every open panel reloads one time.