BUG/REG: RollingGroupby MultiIndex levels dropped
- [x] closes #38523
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

This was accidentally caused by https://github.com/pandas-dev/pandas/pull/37661 where I thought https://github.com/pandas-dev/pandas/issues/37641 was a bug when it was actually the correct behavior.

Therefore, I had to change the behavior of some prior tests. 
looks like 

pls check that perf is not regressed For the relevant ASV

```
$ asv continuous -f 1.1 upstream/master HEAD -b rolling.GroupbyLargeGroups

· Creating environments
· Discovering benchmarks
· Running 2 total benchmarks (2 commits * 1 environments * 1 benchmarks)
[  0.00%] · For pandas commit 9f1a41de <master> (round 1/2):
[  0.00%] ·· Building for conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt........................................................................
[  0.00%] ·· Benchmarking conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt
[ 25.00%] ··· Running (rolling.GroupbyLargeGroups.time_rolling_multiindex_creation--).
[ 25.00%] · For pandas commit 68beb5a5 <bug/rolling_groupby> (round 1/2):
[ 25.00%] ·· Building for conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt..
[ 25.00%] ·· Benchmarking conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt
[ 50.00%] ··· Running (rolling.GroupbyLargeGroups.time_rolling_multiindex_creation--).
[ 50.00%] · For pandas commit 68beb5a5 <bug/rolling_groupby> (round 2/2):
[ 50.00%] ·· Benchmarking conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt
[ 75.00%] ··· rolling.GroupbyLargeGroups.time_rolling_multiindex_creation                                                     30.3±0.6ms
[ 75.00%] · For pandas commit 9f1a41de <master> (round 2/2):
[ 75.00%] ·· Building for conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt..
[ 75.00%] ·· Benchmarking conda-py3.8-Cython0.29.21-jinja2-matplotlib-numba-numexpr-numpy-odfpy-openpyxl-pytables-pytest-scipy-sqlalchemy-xlrd-xlsxwriter-xlwt
[100.00%] ··· rolling.GroupbyLargeGroups.time_rolling_multiindex_creation                                                       26.5±2ms

BENCHMARKS NOT SIGNIFICANTLY CHANGED.
``` for future issue (these are various return values now, using 1.0.5)

```
In [140]: df.reset_index().groupby('Animal').rolling(2).sum()                                                                                           
Out[140]: 
          Max Speed
Animal             
Falcon 0        NaN
       1      740.0
Parrot 2        NaN
       3       50.0

In [141]: df.reset_index(level=0).groupby('Animal').rolling(2).sum()                                                                                    
Out[141]: 
                Max Speed
Animal Type              
Falcon Captive        NaN
       Wild         740.0
Parrot Captive        NaN
       Wild          50.0

In [142]: df.reset_index().groupby('Animal', as_index=False).rolling(2).sum()                                                                           
Out[142]: 
     Max Speed
0 0        NaN
  1      740.0
1 2        NaN
  3       50.0
``` thanks @mroeschke pls open an issue for 1.3 to discuss what we should do with this. @meeseeksdev backport 1.2.x > Before `groupby().rolling()` under the hood was `groupby().apply(lambda x: x.rolling()...)` and therefore `group_keys` impacted the result (since the argument is only applicable for `groupby().apply()`).
>
> After `groupby().rolling()` moved away from using `apply`, `group_keys` didn't impact the result.
>
> So IMO, `group_keys` shouldn't have ever really influenced the result since `groupby().apply()` was never called directly from the user.

You could also interpret that as "because of how it was implemented, `group_keys` has always worked for `.rolling()` in practice (so it basically worked for `apply()` ànd `rolling()`), so the fact that it no longer works now is a regression"

I don't think we should hurry in adding this fix to 1.2.x. Let's first properly discuss what behaviour we want (because we *could* end up going back again to the previous behaviour ..) Exploring the return value across the recent pandas versions for one of the cases: https://nbviewer.jupyter.org/gist/jorisvandenbossche/500ff1d082c288c378dc1972e24e6b4e