ENH: Support na_position for sort_index and sortlevel

[phofl]

• closes BUG: na_position ignored when sorting MultiIndex with level!=None #51612 (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations 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.

I think the special casing in sort level was done for performance reason. Avoiding the use of categorical solves this. Both branches were equally fast

%timeit midx.sortlevel(level=[0, 1], ascending=[True, True])
58.8 ms ± 674 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
%timeit midx.sortlevel(level=[0, 1], ascending=True)
60.7 ms ± 278 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

[mroeschke]

Thanks @phofl

[rhshadrach]

@phofl - any reason to default to first here? With a quick grep I'm seeing we default to last everywhere else.

[phofl]

Pretty sure that this was done for backwards compatibility reasons. Does this break anything?

[rhshadrach]

Nope - makes sense. I'll experiment with changing the default and see what breaks; depending on that may put up an issue to deprecate.

[phofl]

No objections to deprecate. IIRC this is used internally a bunch, so deprecating might be tricky

[rhshadrach]

Ah - I meant just deprecating the default and changing it to "last" to be consistent with other sorting methods. We can still specify "first" internally so hopefully it will be straight forward unless I'm missing something.

[phofl]

Ah got you. No that makes sense