st.timezones() strategy using the stdlib zoneinfo module

[Zac-HD]

From one perspective, this is a pretty standard PR adding a new strategy - it's almost identical to the hypothesis.extra.{dateutil,pytz}.timezones() strategies, but in the hypothesis.strategies namespace because the timezones in question come from the standard library.

On the other hand, they're only in the latest stdlib, so we also have some logic to manage backports - mostly through a new hypothesis[zoneinfo] extra which has only conditional dependencies. This is clearly documented and raises nice errors if you don't have the deps; and since it'll be standard eventually I'd prefer to put it in the right place to start with.

Implementation of allow_aliases and allow_deprecated arguments for timezone_keys() has been left to a future PR, along with #2414 - this is just the increment to get a minimal useful API out there. Closes #2630.

[PiDelport]

I added some questions, but this looks good!

[pganssle]

This broke backports.zoneinfo's test suite (mainly because backports.zoneinfo's test suite relies on importing backports.zoneinfo in its own weird way.

Not that you need to change anything, just thought it's kinda funny.

[pganssle]

Implementation of allow_aliases and allow_deprecated arguments for timezone_keys() has been left to a future PR, along with #2414 - this is just the increment to get a minimal useful API out there. Closes #2630.

It's not clear how easy it would be to implement such a thing using only the time zone data on disk. You may be able to detect if a given zone is a hard link to another zone, but I'm not actually sure if the hard links are guaranteed to point to the canonical zone (as opposed to a random one). dateutil has some sort of zone deduplication logic in the code that builds the zoneinfo tarball and it seems to consistently map America/New_York to US/Eastern rather than the other way around. I haven't tried very hard to fix that.

You can probably hard-code a list of existing deprecated zones like anything in Etc/ or US/, though. Not to discourage you from trying to find a programmatic way to detect these (I haven't spent enough time to rule out that it can be done), just might be good to temper expectations if you open an issue for this and some new contributor comes by thinking it might be easy 😛.