COMPAT: Argsort position matches NumPy
Closes https://github.com/pandas-dev/pandas/issues/29884

Bit of a WIP, CI is probably going to fail here. One API question, do we want NaT to sort at the end, regardless of the NumPy version? Or should we match the behavior of the installed NumPy (NaT at the start for <1.18, at the end for >=1.18)?
Perf looks OK I think

```python
import pandas as pd
import numpy as np

arr = np.arange(10000)
np.random.shuffle(arr)
idx = pd.DatetimeIndex(arr)

%timeit idx.sort_values()

idx = pd.PeriodIndex(ordinal=arr, freq='D')
%timeit idx.sort_values()
```

Master

```
403 µs ± 10.6 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
450 µs ± 9.41 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

PR

```
421 µs ± 3.39 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
468 µs ± 8.29 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
```

Not sure why they aren't identical yet. We're a bit outside the standard deviation on those runs. > Not sure why they aren't identical yet. We're a bit outside the standard deviation on those runs.

i think we get one, maybe two extra function-call-overheads; does that account for 15-20 microseconds? > im a bit confused by this. how is this prevented from varying based on the numpy version?

That was my [original question](https://github.com/pandas-dev/pandas/pull/31210#issue-365909033). Do we want to match the installed version of NumPy so that `np.sort(ndarray[m8[ns]])` matches `np.sort(DatetimeIndex), regardless of the NumPy versoin`? Or  do we want to adopt the new behavior of sorting last regardless of the NumPy version?

Both seem quite difficult, given that we sometimes do things like sort the datetimes, extract the i8 values, and then operate on them assuming they're sorted. I'm not confident that I can get this done for 1.0, if ever. > I'm not confident that I can get this done for 1.0, if ever.

This does sound like the kind of problem that goes away on its own once our numpy min-version catches up.  I lean towards "dont sweat it" I'm going to close this to get it out of the way. @TomAugspurger what was missing / wrong / not yet working in the current PR? (or just still a lot of failing tests that need further investigation?) Anything that relied on `.sort_values().asi8` to be sorted was broken / incorrect. This includes `.rolling`, `.resample`, etc. Also affected: the ability to have DatetimeIndexOpsMixin.argsort dispatch to self._data.argsort Ah, that indeed sounds more complicated :)