ENH: provide standard BaseIndexers in pandas.api.indexers
- [X] closes #33201
- [X] 1 test modified / 1 passed
- [X] passes `black pandas`
- [X] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [X] whatsnew entry

This PR adds a forward-looking `pandas.api.indexers.BaseIndexer` subclass implementation and exposes it to users as discussed in #33180 .

### Exposing other indexers

It is also possible to expose a backward-looking indexer simply by exposing `pandas.core.window.indexers.FixedWindowIndexer` through the API. Seems redundant to me as this is basically the same as supplying an integer as the window argument when creating a rolling object but it can be done for consistency. I'd be grateful for a discussion.

### Note on tests

The class is incorporated into `test_rolling_forward_window` in `test_base_indexer.py` and this serves as a test that the new indexer is working correctly.

### Notes on performance
I've tested the implementation and it shows comparable performance to `pandas.core.window.indexers.FixedWindowIndexer`. In my tests the new indexer was slightly faster, either by luck, or because I streamlined the backward-looking indexer a bit when making the forward-looking one.
/azp run <samp>
Azure Pipelines successfully started running 1 pipeline(s).<br>

</samp> looks good, if you can rebase and make the change to use the FixedForward indexer. Also I think worthile adding a benchmark. @TomAugspurger @jorisvandenbossche @jbrockmendel if any comments. Travis failing has nothing to do with this PR. See #33280 
Waiting for merge. Could you document this new indexer around here: https://pandas.pydata.org/pandas-docs/stable/user_guide/computation.html#custom-window-rolling Found a bug in the benchmark, needs a bit more work.

UPDATE: fixed it and tested locally, the new benchmark is working now. @mroeschke Added documentation to the custom window rolling subsection. Can introduce a new subsection, but I think it fits in. Please tell me what you think. @jreback 
Rebased, changed the test, added a benchmark to the suite. All green. LGTM Small change: had forgotten to include versionadded in the user guide. Included it. Looks like the doc build fail is being handled in #33309  @jreback 
All green, pinged you on relevant changes. I think I've addressed everything, but I'm not sure if I understood you correctly on adding refs and the ipython block. Please tell me if I misunderstood anything. @jreback 
Thanks for the clarification! Sorry for getting confused: first time adding a public class.
1. Added an entry to the `window.rst` so that the docstrings get published as part of API reference output.
2. Made the links in the user guide clickable and tested locally.
3. Replaced the `code-block` with an `ipython` block. Thanks.
4. Added `pytest.raises` to test error-raising behavior. I think having it in the same test works, but please tell me if you'd rather have error-raising behavior be a separate test. thanks @AlexKirko very nice!