FEAT-#6983: Add Pluggable Documentation Module Support

[sfc-gh-dpetersohn]

What do these changes do?

Add support for custom documentation defined at runtime.

• first commit message and PR title follow format outlined here

  NOTE: If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

• passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
• passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
• signed commit with git commit -s
• Resolves Documentation plugin #6983
• tests added and passing
• module layout described at docs/development/architecture.rst is up-to-date

[sfc-gh-dpetersohn]

This PR doesn't change anything about the current behavior when it comes to docs, it only applies changes when the developer wants to modify the docs with this class.

We may want to use this in the future to have different docs for Ray, Dask, or other engines.

[sfc-gh-dpetersohn]

These had to be added to both Series and DataFrame because they share docs, but we may not want them to in the Documentation class.

In a separate PR, I think we should add the rest of these, but for now I have left it to these two as a proof of concept for what will be needed in the future. The tests will not pass if we do not have the distinction with Series and DataFrame.

[YarShev]

Also, many jobs failed. Please take a look.

[YarShev]

This PR doesn't change anything about the current behavior when it comes to docs, it only applies changes when the developer wants to modify the docs with this class.

We may want to use this in the future to have different docs for Ray, Dask, or other engines.

Could you elaborate a bit on why we may want to have different docs Ray, Dask, or other engines?

[sfc-gh-dpetersohn]

Could you elaborate a bit on why we may want to have different docs Ray, Dask, or other engines?

Some engines may have different expectations, particularly databases. If a database engine doesn't have the same guarantees as Ray or Dask, it should be reflected in the documentation.

[YarShev]

@sfc-gh-dpetersohn, got it, thanks for the clarification. CI is still failing, please take a look. For instance, lint (pydocstyle) failed because of the following error.

D200: One-line docstring should fit on one line with quotes (found 3)

[sfc-gh-dpetersohn]

Thanks for the ping @YarShev, I think I fixed everything (we will see if it passes 😄). It seems we are not super consistent with D200 on pydocstyle since there are multiple instances of the docstrings being formatted this way. I will fix the new ones in this PR but maybe we should consider more standardization in the future?

[YarShev]

Thanks for the ping @YarShev, I think I fixed everything (we will see if it passes 😄). It seems we are not super consistent with D200 on pydocstyle since there are multiple instances of the docstrings being formatted this way. I will fix the new ones in this PR but maybe we should consider more standardization in the future?

I see that we are really not consistent with D200. We just put noqa: D200 in those places but we should definitely consider more standardization on this matter in the future.

[YarShev]

@sfc-gh-dpetersohn, build docs is the last job left to fix. Can you take a look? It seems the issue relates to docstrings from which we build docs.

[sfc-gh-dpetersohn]

@YarShev finally figured out the issue

[YarShev]

@sfc-gh-dpetersohn, LGTM, thanks!