ENH: Consider adding alternative calculation of centered moving averages for even window size
- [x] I have checked that this issue has not already been reported (originally reported in the now quite old #14425 but reviving here with a more thorough description of the problem)

- [x] I have confirmed this bug exists on the latest version of pandas.

- [ ] (optional) I have confirmed this bug exists on the master branch of pandas.

---
#### Code Sample

The current `rolling(window, center=True).mean()` behaviour in Pandas first calculates the rolling mean and then shifts the result back to "center" the labels. This does not give the expected result (at least to me):

```python
import pandas as pd
window_size = 2
df = pd.DataFrame([2, 6, 4, 2, 0, 1, 5, 3],
                  index=["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug"])
df.rolling(window=window_size).mean()
```

|     |     0 |
|:----|------:|
| Jan | nan   |
| Feb |   4   |
| Mar |   5   |
| Apr |   3   |
| May |   1   |
| Jun |   0.5 |
| Jul |   3   |
| Aug |   4   |

#### Problem description

For rolling averages with an even sized window (e.g., 2, 4, 6, 8, etc.) [it is common](https://otexts.com/fpp2/moving-averages.html#moving-averages-of-moving-averages) to apply a moving average with window size = 2 (`2 x MA`) to the result of the original moving average output to line up results with the original index. 

Here's an example animation showing the expected behaviour:

![2-moving-average](https://user-images.githubusercontent.com/40379073/110401570-a335e000-802e-11eb-9341-cf31365fa74b.gif)

#### Expected Output

The following code achieves the above (correct?) behaviour:

```python
(df.rolling(window=window_size).mean()
   .rolling(window=2).mean()
   .shift(-window_size // 2)
)
```

|     |      0 |
|:----|-------:|
| Jan | nan    |
| Feb |   4.5  |
| Mar |   4    |
| Apr |   2    |
| May |   0.75 |
| Jun |   1.75 |
| Jul |   3.5  |
| Aug | nan    |

#### Additional context

I'm not sure if this needs to be changed in the codebase as the above workaround is not too bad. But I wanted to document the issue here for anyone who encounters it. I'd also be happy to work on a PR if this did want to be implemented.

#### Output of ``pd.show_versions()``

<details>

INSTALLED VERSIONS
------------------
commit           : f2c8480af2f25efdbd803218b9d87980f416563e
python           : 3.9.2.final.0
python-bits      : 64
OS               : Darwin
OS-release       : 18.7.0
Version          : Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
machine          : x86_64
processor        : i386
byteorder        : little
LC_ALL           : None
LANG             : en_CA.UTF-8
LOCALE           : en_CA.UTF-8

pandas           : 1.2.3
numpy            : 1.20.1
pytz             : 2021.1
dateutil         : 2.8.1
pip              : 21.0.1
setuptools       : 49.6.0.post20210108
Cython           : None
pytest           : None
hypothesis       : None
sphinx           : None
blosc            : None
feather          : None
xlsxwriter       : None
lxml.etree       : None
html5lib         : None
pymysql          : None
psycopg2         : None
jinja2           : None
IPython          : None
pandas_datareader: None
bs4              : None
bottleneck       : None
fsspec           : None
fastparquet      : None
gcsfs            : None
matplotlib       : None
numexpr          : None
odfpy            : None
openpyxl         : None
pandas_gbq       : None
pyarrow          : None
pyxlsb           : None
s3fs             : None
scipy            : None
sqlalchemy       : None
tables           : None
tabulate         : None
xarray           : None
xlrd             : None
xlwt             : None
numba            : None

</details>
