Drop python 3.10; increase required dependency versions

[kandersolar]

• [ ] Closes #xxxx
• 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 no AI
• [ ] 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.

Python 3.10 reaches end of life in October (https://devguide.python.org/versions/). May as well remove it now. And, dropping support for 3.10 means we can increment our dependencies to exclude old versions that can't be installed on python 3.11+.

[kandersolar]

Ready for review. The test failure is unrelated and looks like the kind of thing that might go away on its own.

[cwhanse]

This decorator should go

pvlib-python/tests/conftest.py

Line 227 in b3d09bf

# single-diode equation functions have method=='chandrupatla', which relies

here, or in a different maintenance PR?

[kandersolar]

I think we do not want to make any changes to that decorator. With this PR the minimum scipy advances to 1.9.2. I think we should only remove that decorator when it eventually reaches 1.15 and pvlib can assume that chandrupatla is always available.

[cwhanse]

Right - 1.9 < 1.15 in semantic versioning

[RDaxini]

For my own understanding/knowledge... in the case of no associated bugs/test failures, how are these changes decided? These changes being which specific version of other dependencies are required, and when to implement the update/min version requirements in general.

[kandersolar]

Taking scipy as an example, our previous minimum of 1.7.2 is not available for python 3.11 or higher (check PyPI), meaning after this PR it cannot be installed easily on any python version we support. It would be difficult for us to test it in CI, and there is likely little benefit to users anyway (since they cannot install it either). So, it makes sense to increase our minimum version to something that can be installed on a python version we support. For scipy, the first version to support python 3.11 was 1.9.2, so that's where I set our new minimum.

I note that other large projects take a more aggressive approach to updating their minimum versions. For example, see NEP 29 and SPEC 0, which suggest supporting only dependency versions released in the last two years. We don't see why dropping usable versions makes sense (see #828 (comment)), so we don't follow those guidelines for pvlib.