ENH/BUG groupby nth now filters, works with DataFrames
fixes #5552

partial for #5264

```
In [101]: df = pd.DataFrame([[1, np.nan], [1, 4], [5, 6]], columns=['A', 'B'])

In [102]: g = df.groupby('A')

In [103]: g.nth(0)
Out[103]:
   A   B
0  1 NaN
2  5   6

In [104]: g.nth(1)
Out[104]:
   A  B
1  1  4

In [105]: g.nth(-1)
Out[105]:
   A  B
1  1  4
2  5  6

In [106]: g.nth(0, dropna='any')  # old behaviour-like
Out[106]:
   B
A
1  4
5  6

In [107]: g.nth(1, dropna='any')  # old behaviour-like
Out[107]:
    B
A
1 NaN
5 NaN
```

Also note old behaviour was not stable/correct for negative (now fixed with PR&dropna):

```
In [9]: g.nth(-3,)
Out[9]:
               B
A
1  2.144760e-314
5  2.124748e-314

In [10]: g.B.nth(-3,)
Out[10]:
A
1    2.144760e-314
5    2.144337e-314
Name: B, dtype: float64
```
 If you get around to it; I suspect the new method is MUCH faster than the old, so maybe add a vbench
 will append a vbench. Is much faster except when applying to dataframe with dropna (old-style) it's a little slower, but that was previously borked.

Um, obviously there is overlap with first and last methods, they be got with nth(0) and nth(-1) but not tested the differences yet... you reckon these should change too?
 yes I think you should blow away first/last code and just alias them to `nth(0)` and `nth(-1)`.

reminds me that pls put some tests that deal with different types (because first/last have this convert arg..though not sure why)
 though maybe `nth(0)` (first) and (iloc[0]) deserver a fast-path as it doesn't need the machinery of cumcount
 there was/is a weird test for types of first/last/nth, I tweaked it a little but is still there...

I can iterate tests over a few of the same df (but with different column types), is that what you mean?

Yea, re fast path (will see how they compare the the cumcount for now)...
 Added vbench, is about 40 times faster with not-including the setup of the groupby (which is included in the bench)
 awesome!
