Short-term follow-ups for descending sorts #31423

Descending sorts have two higher profile issues right now:

• object and void/structured dtype aren't yet implemented. There are two approaches here:
  1. Make the generic path work and live with possibly weird NaN logic (this is the current state in practice, even though compare implementors could choose differently).
  2. Focus on object and just implement it explicitly. We could make a choice such as val != val to define "unorderable" so that the object sort would sort nan-like objects to the end.
     (This will be awkward for void/structured so that might be an omission in this path unless we do 1+2. lexsort is better this way, but a different thing to attack.)
• Paths currently vectorized via x86-simd-sort don't support descending=True because of the different NaN semantics, this will be a trivial fix once this is finalized: Add trailing_nans parameter to control NaN placement in sort results x86-simd-sort#235
  • Not complicated, I will argue this is backportable as a performance bug fix if need be.

I hope we can solve both for 2.5, but if anyone feels these are blockers, please comment (then we could even just disable the Python entrypoint for now).