DOC: Add missing attributes and methods to MultiIndex API documentation
- [x] xref #50496  (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
- [x] 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.

I see now that this only partially addresses the issue. I changes `closes` in the description to `xref` for now, so we don't close the issue yet if this is merged. But would be great if you can also fix the problem in the left side menu, where some methos/attributes of MultiIndex are under the MultiIndex object, and some are listed independently after `IndexSlice`.

The problem seems to be in https://github.com/pandas-dev/pandas/blob/main/doc/source/reference/indexing.rst#multiindex

I'm not fully sure how Sphinx manages those autosummaries. Seems like some of the attributes/methods are added automatically, while many others are added manually in different sections. This doesn't only affect `MultiIndex`.

Maybe I can suggest to move `IndexSlice`  to not be in the middle of `MultiIndex` in this PR, and then address the problem in the sidebar separately.

What do you think @Elvislim1991 ? Thanks for working on this! Ya, I realize the issues on the sidebar as well. As you said, It happens on all the methods so I thought it's good to keep it. I think it will be cleaner to just show the higher level as well. I can try doing that as well in this PR. What do you think @datapythonista?

For the IndexSlice, I agree for aesthetics better to place it out of MultiIndex but close to it as IndexSlice is closely related to it.  I expect this PR, including moving IndexSlice to be non-controversial and merged quickly. While grouping things in the sidebar can be trickier, and also more opinionated. If we use separate PRs, we'll get this part merged faster, and we won't need to keep reviewing the changes here while discussing about the sidebar grouping.

No big deal, since changes here are small, but that's why I suggested splitting the PRs this way. But up yo you. Okay, I will just touch the IndexSlice for this PR.  Ok, I will move back IndexSlice under MultiIndex.  Thanks @Elvislim1991 