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.
• 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`).
• Pull request is nearly complete and ready for detailed review.
• 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 #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