BUG: groupby.nth should be a filter
- [x] closes #13666 (Replace xxxx with the GitHub issue number)
- [x] [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).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Thanks @mroeschke - ready for another look. Hmm I'm not sure I agree with this approach - doesn't this introduce an even larger inconsistency now between nth / first / last? Do we have other groupby functions that work this way? > Hmm I'm not sure I agree with this approach - doesn't this introduce an even larger inconsistency now between nth / first / last? Do we have other groupby functions that work this way?

`first` and `last` are reductions - they return 1 value per group. `nth` on the other hand can also return zero or multiple rows. It is because of this I think we should be treating `nth` as a filtration. The other filtrations, `head`, `tail`, and `filter` all behave as in this PR, namely they merely filter the rows from the input object. In particular, `groupby(...).head()` now behaves the same as `groupby(...).nth([0, 1, 2, 3, 4])`. Yea I definitely see the argument. I think I'm +/-0 . IIUC this makes nth closer to filtering on rank, but with a predetermined option for a tiebreaker > IIUC this makes nth closer to filtering on rank

nth goes off of the input order, making it somewhat different from rank. Awesome work @rhshadrach 