BUG: stabilize sort_values algorithms for Series and time-like Indices
- [X] closes #35922
- [X] 18 tests changed / 18 passed
- [X] passes `black pandas`
- [X] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [X] whatsnew entry

## Problem

Our `sort_values` functions currently behave differently for different objects: for most `Index` subclasses they are stable when sorting in descending order (this was introduced by #35604), but for DateTime-like `Index` subclasses and `Series` they are unstable. This isn't good as sorting should be stable across the board.

## Details

Came across this one while introducing missing-value support to `Index.sort_values` in #35604, so I had to limit that PR to non-DateTime-like `Index` subclasses. The problem was that we had different expectations for sorting stability baked into our test suite, so unifying sorting algorithms and missing-value support needed a bunch of careful test changes and altering both `sort_values` and algorithms in `sorting.py`.

Since this PR necessarily includes changes in several places, I have commented on all the changes made in the code and the unusual changes in the tests to make reviewing the code easier (see "On test changes" below).

## On test changes

Most changes I made in the tests are for cases where we were expecting an unstable sort or expected NaNs to be sorted to the beginning of a list of duplicates for ascending sort and to the end for descending (we forced this by inserting NaN-likes at 0 position and reversing when sorting in descending order in `Series.sort_values`).

## Default behavior changes

Since DateTime-like `Index` subclasses now support `na_position` using the same implementation as the other `Index` subclasses, they now sort missing values to the end of the `Index` by default.

## Performance

Ran the full benchmark suite, and there are no performance regressions.

## Out-of-scope

The only type I didn't touch so far is MultiIndex. It can't be sorted the same way through nargsort, and I don't think we should be doing it in this PR, if it all (stabilizing descending order MultiIndex.sort_values will definitely be a PITA, and it's a very narrow use case, in my opinion).