Fix ZoneInfo handling in datetime constructor

[binggao1230]

• This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Fixes #126.

This updates hightime.datetime.__new__ to treat any datetime.tzinfo instance as the positional tzinfo argument that can be passed internally by datetime.datetime, instead of only accepting datetime.timezone. It also adds regression coverage for ZoneInfo("America/Chicago") through both now(tz=...) and astimezone(...).

Why should this Pull Request be merged?

ZoneInfo and other tzinfo subclasses are valid timezone values. Before this change, hightime interpreted them as its femtosecond argument and raised TypeError, which broke now(tz=ZoneInfo(...)) and astimezone(...).

What testing has been done?

• .venv/bin/python -m pytest tests/test_datetime.py::test_datetime_now_with_zoneinfo tests/test_datetime.py::test_datetime_astimezone_with_zoneinfo -q
• .venv/bin/python -m pytest tests/test_datetime.py -q
• .venv/bin/python -m pytest -q
• .venv/bin/ni-python-styleguide lint
• .venv/bin/mypy
• .venv/bin/bandit -c pyproject.toml -r hightime
• Manual ZoneInfo("America/Chicago") reproduction for now(tz=...) and astimezone(...)

[bkeryan]

@gaoflow, thank you for contributing.

The new tests are currently failing on Windows because the system time zone data is not installed by default on Windows. I opened #138 to address this. After that PR is merged, your updated tests should pass and I will merge this PR.