Address various deprecations and test issues with pandas 2.2.0

[kandersolar]

• [ ] Closes #xxx
• [ ] Added tests to cover all new or modified code.
• [ ] Clearly documented all new API functions with PEP257 and numpydoc compliant docstrings.
• [ ] Added new API functions to docs/api.rst.
• [ ] Non-API functions clearly documented with docstrings or comments as necessary.
• [x] Adds description and name entries in the appropriate "what's new" file in docs/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`).
• [x] Pull request is nearly complete and ready for detailed review.
• [x] Maintainer: Appropriate GitHub Labels and Milestone are assigned to the Pull Request and linked Issue.

A recent run of the test suite reported 262 warnings, mostly these deprecation warnings from pandas:

• FutureWarning: 'T' is deprecated and will be removed in a future version, please use 'min' instead.
• FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead.
• FutureWarning: Setting an item of incompatible dtype is deprecated and will raise an error in a future version of pandas. Value '[...]' has dtype incompatible with int64, please explicitly cast to a compatible dtype first.
• FutureWarning: Downcasting object dtype arrays on .fillna, .ffill, .bfill is deprecated and will change in a future version. Call result.infer_objects(copy=False) instead. To opt-in to the future behavior, set pd.set_option('future.no_silent_downcasting', True)
• FutureWarning: Series.__getitem__ treating keys as positions is deprecated. In a future version, integer keys will always be treated as labels (consistent with DataFrame behavior). To access a value by position, use ser.iloc[pos]

Fixing the first couple is a find/replace exercise. The others needed minor code rewrites.

[kperrynrel]

@kandersolar went ahead and added updates to the documentation gallery examples that handle the T->min conversion

[kperrynrel]

This is preemptive, but should I include pyarrow as a package dependency and not just a doc dependency because of this? This would be in PR https://github.com/pvlib/pvanalytics/pull/202

[kperrynrel]

Otherwise LGTM!

[kandersolar]

This is preemptive, but should I include pyarrow as a package dependency and not just a doc dependency because of this?

No action needed on our part, I think. That is just pandas giving users a heads up that someday pip install pandas will bring pyarrow along with it, and that could cause problems in some situations (e.g. small computing environments where an additional heavy-ish dependency like pyarrow might be an unwelcome surprise). Doesn't matter for us, although I guess the warning message is a minor nuisance :P