DEPR: be stricter in assert_almost_equal
- [ ] 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
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

xref #18463 this doesn't get us all the way there since assert_index_equal and assert_numpy_array_equal go through different paths.

Note the many tests that needed to be changed; some of these likely represent undesired behaviors.

@phofl i found a usecase for downcast=False in fillna!
Thanks @jbrockmendel  This turns out to be a bit annoying while updating pyarrow tests for certain cases. For example, we have tests where we check that in the input you can have mixed NA-likes values. To assert the result, with this PR we need to construct the expected data with a consistent NA value. For small data it's typically straightforward to redefine it correctly. For larger data, that's a bit more annoying though.

One thing that also doesn't help is that we don't allow filling NAs with `None` (pyarrow uses None for object dtype arrays when converting to numpy/pandas): `df.fillna(None)` errors.

Should we also consider adding a keyword for relaxing this, so you can override the strict default for cases you don't care about the difference? (which was also suggested in https://github.com/pandas-dev/pandas/issues/18463) Any chance of getting a flag in `assert_X_equal()` to restore the old behaviour? It's very useful when using `check_dtype=False`.

Or maybe it could be connected to `check_dtype` (restoring the old behaviour when False)?