refactor: deprecate pytz in favor of builtin zoneinfo

[JoLo90]

Description

Replaces pytz with Python's built-in zoneinfo module for all timezone handling in pvlib.
There is an ongoing issue with micromamba that has been solved thanks to mamba-org/setup-micromamba#306. See commit [ci: update micromamba setup and version].

Changes

• pvlib/tools.py: Replaced all pytz.utc.localize() and pytz.timezone() calls with datetime.timezone.utc and zoneinfo.ZoneInfo
• pvlib/iotools/pvgis.py: Replaced pytz.timezone() with zoneinfo.ZoneInfo
• pvlib/solarposition.py: Updated docstring to remove reference to pytz.exceptions.AmbiguousTimeError
• ci/requirements-py3.1*.yml: updated mamba-org/setup-micromamba from v2 to v3 to fix Windows runner incompatibility with the new windows-2025 GitHub Actions runner
• docs/tutorials/solarposition.ipynb: Replaced tus.pytz with tus.tz
• tests/: Updated all test files to use zoneinfo instead of pytz

Checklist

• Closes Replace pytz with standard library's zoneinfo #2343
• I am familiar with the contributing guidelines
• I attest that all AI-generated material has been vetted for accuracy and is in compliance with the pvlib license
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

[cwhanse]

@JoLo90 thanks for taking this on. Am I correct in thinking that, other that removing Location.pytz and needing to install pytz on Windows, that the changes are transparent to users?

Since the intent is to remove Location.pytz, we'll want to keep Location.pytz working for a deprecation period and raise a deprecation message if it is accessed or assigned (I think).

[JoLo90]

@cwhanse
Yes, the changes are transparent to users, unless they were using the pytz property. As you mentioned, we should first show a warning that the property is deprecated.
Would the following make sense?

    Deprecated since 0.15.2
    Will be removed in 0.16.0 

[cwhanse]

@JoLo90 We'd remove in 0.17.0.

I think we raise a deprecation warning here using the pvlib function warn_deprecated here.

At least I think that's how the deprecation is intended to work for a class attribute.