Consider implementing own system timezone logic

[ariebovenberg]

Currently, whenever relies on the standard library for handling the system timezone. The drawbacks are starting to outweigh the benefits.

The benefits:

1. less code—simply reuse what already exists
2. whenever behaves like the Python standard library regarding the system timezone
3. whenever doesn't need to have a (public) API for posix timezones or TZif files

The drawbacks:

1. requires an extra class SystemDateTime, with less-than-ideal semantics. No other major library has this abstraction—it looks silly 😉
2. the actual system timezone name can't be read.
3. the system timezone can only be patched through tzset() which doesn't work on windows

Thoughts:

• if the system tz can be retrieved directly, ZonedDateTime could be used and SystemDateTime could be deprecated.
• to_system_tz() method would remain, and look up the system tz name, and create a ZonedDateTime with the given tz ID. Or should there be a "magic string" like "system"? Or should tz=None imply the system timezone? hmmmm...
• ZonedDateTime could default to the system tz in some cases. Would have to balance convenience with explicitness.
• system TZ ID would probably have to be cached. For both predictability and performance. This would require a dedicated helper function to "reload".
• using the tzlocal package would be a lot easier, but this doesn't support POSIX strings or custom TZif files. Maybe there's some way around this...
• using jiff isn't an option either, since the pure-Python version couldn't use it
• POSIX or custom TZif files would require ZonedDateTime to support these, which opens a can of worms of expanding the types of tz allowed (Custom timezones (tzinfo or other providers) #65).

edit: clarifications