RFC CLI Tool Proposal

## Introduction
Other OSS projects such as `scipy` and `numpy` have made use of development CLI tools such as `runtests.py` and `dev.py` to provide a collected and singular entry point into development tasks for contributors. I find these tools very helpful personally, and think they add a large amount of value, especially for onboarding new contributors. Recently Pandas has also begun discussion and implementation of their own development CLI tool. @noatamir has made a great writeup on some of the benefits and justifications for such a tool (see: https://github.com/pandas-dev/pandas/issues/47700). I highly recommend taking the time to read their writeup. 

Some of the benefits of such a tool include:
1. Increased discoverability of tools, decreasing time spent jumping around documentation. This is especially helpful for those who may not read every single word of documentation (such is my bad habit 😅).
2. Consistency for CI and development. We can establish a 1-1 between CI checks and `dev.py` commands, e.g. `dev.py lint` which could then impose both `black` and `isort` (cf. https://github.com/scikit-learn/scikit-learn/issues/22853)
3. Ease of installation. Users could install whatever dependencies are necessary depending on what workflow they want enabled. A call to `dev.py doc build` could check for the presence of the necessary dependencies and install if needed (or optionally prompt).
4. Reduced barrier to entry. Quite frankly, having to run various commands for tasks, anywhere from linting to building C sources, can be overwhelming, especially to new developers.

Recently `scipy` explored a new solution for developing a unified development CLI tool (cf. https://github.com/scipy/scipy/issues/15489) based on [`do.it`](https://pydoit.org/). Pandas is also exploring a `do.it` based [solution](https://github.com/pandas-dev/pandas/issues/47700). There's been good feedback on this framework and I would propose the same.

## Encompassed Actions
Some actions which would be wrapped by such a development CLI include:
- Dependency installation (could be per-workflow)
- Testing
- Linting
- Extension building
- Documentation building
- Pre-commit installation

## Considerations
As with all things, the question is whether the benefits outweigh the maintenance cost. While projects like scipy with many complex workflows benefit the most from such a tool, personally I think anything to decrease the barrier to entry for scikit-learn development is worth considering.

If we do opt to build such a tool, we can make use of the work already done in scipy as well as the recently released separate [`dev.py` package](https://github.com/scientific-python/dev.py). Either way, the largest modification we'd need to make is alter the `build` command to use `setuptools` instead of `meson`, though that shouldn't be too problematic.

COMMENT:
I have been tagged, I dare comment then... :)

I believe adding layers to the development environment makes more difficult to solve the issues in the code.
We often saw that already, when users report possible bugs using, eg, Jupyter Notebooks in docker containers hosting conda environments. This is an old issue and produced some tense exchanges in the past between maintainers and packagers.
Those tools are great for users, in teaching applications or in production, but explicitly hide the mechanics of the code, which is what we don't want at the development stage.

From the contributor point of view I agree with @adrinjalali comment:

> If a new contributor comes, fixes a documentation issue, and runs a few custom CLI commands, the only thing they get out of it is that they can put scikit-learn on their github's profile page and say that they have contributed to the project. They haven't actually learned anything, is that a good thing? I'm not sure. I feel like we're expecting less and less from our contributors, and that might not be in their benefit.

I'd rather improve the documentation, not only the one for users but for maintainers too.
I'm afraid sometime back and forth from documentation are necessary to understand how things work, I guess we are all guilty of not reading it as much as is needed, but there is no other solution than going back and looking again at it... and this is true also at the editing stage: the contributor documentation could benefit of quicker updates, even if it is not always perfect, so it could be used by more people and improved in faster iterations.

In particular the PR checks could be better explained and backed by bots to explicit the errors, as said above: I am often doing the job of the bot ... :) ... I believe this is a very valuable information for contributors who don't always come from a background of software development and face for the first time the challenge of the integration.

Finally, I believe that the backlog of pull requests and issues to be addressed is already quite big, without adding new workloads for the developers.

Labels: RFC, workflow