More calendar timezone fixes, datetime handling fixes

[daym]

• More calendar timezone fixes
• datetime handling fixes for recurrences (for USE_TZ=False and for USE_TZ=True)
• Add Event.updater field

Principles:

• When you specify recurring events as a human you want to specify it in local time (since it recurs at the same time in local time regardless of summer-/wintertime changes--for example: in summer, the event starts at 10:00. In winter, the event starts at 10:00 too). Since the rfc generator used for generating events only supports naive datetimes that is modeled with naive datetimes. Have to use those for the rfc generator and eventually convert them to timezone-aware at the boundaries
• Timestamps stored in the database are stored as timestamp with time zone in postgres (which For timestamp with time zone , the internally stored value is always in UTC according to postgres docs) AND I now store a timezone string into the database table schedule_event as well (pytz really wants you to use named timezones--which makes sense because there can be other local variations depending on politics, so the timezone offset is not uniquely identifying what you have to do).
• Python stdlib directly supports datetime with time zone name only starting with python 3.12--which I think is a little too new to require. So I avoid using its features here.

[coveralls]

coverage: 85.26%. first build
when pulling d922193 on daym:update
into bcb48e3 on llazzaro:develop.

[llazzaro]

Hi @daym ,

Thanks for creating this PR, I really appreciate the effort.

Would it be possible to split it into smaller changes? It currently includes several features together, which makes it harder to review and merge. If there is an issue in one part, we cannot merge the others that may already be ready.

Since this project is used in legacy systems, even small changes can affect existing users. Smaller PRs would make it easier and safer to review and integrate.

Thanks again for your work!

[daym]

Would it be possible to split it into smaller changes? It currently includes several features together, which makes it harder to review and merge. If there is an issue in one part, we cannot merge the others that may already be ready.

I've now split out the things that need no DB migration--but with the other ones I cannot really split them up because the migrations have (spurious, but django likes it) dependencies.