API: mode.nan_is_na to consistently distinguish NaN-vs-NA
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

As discussed on the last dev call, this implements `"mode.nan_is_na"` (default `True`) to consider NaN as either always-equivalent or never-equivalent to NA.

This sits on top of

- #62021, which trims the diff here by updating some tests to use NA instead of NaN.  
- #61732 which implements the option but only for pyarrow dtypes.
- #62038 which addresses an issue in `DataFrame.where`
- #62053 which addresses a kludge in read_csv with engine="pyarrow"

Still need to

- [x] Add docs for the new option, including whatsnew section
- [x] deal with a kludge in algorithms.rank; fixed by #62043
- [x] deal with a kludge in read_csv with engine="pyarrow"; fixed by #62053
- [ ] Add tests for the issues this addresses
Discussed in the dev call before last where I, @mroeschke, and @Dr-Irv were +1.  Joris was unenthused but "not necessarily opposed".  On slack @rhshadrach expressed a +1.  All those opinions were to the concept, not the execution.