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 still prefer a `Makefile`, and it's cross platform if windows users use a git bash, and it's designed to simplify workflows.

I have compiled multiple projects, and I've never used their tool. As @glemaitre mentions, it's hard to learn a new CLI for each project one needs to compile/contribute to, whereas I know how `pytest` works, how to install packages, and I know I can probably find stuff in a `Makefile`. We should care about transferable skills.

I do recognize that there's a mismatch between what an experienced user like our core dev community can do and expects, and the average first time contributor to the project.

These things complicate stuff, quite substantially. I used to understand our CI, and I did it the first time I looked at them. But I haven't followed the recent changes to our CI, and now I have absolutely no clue how we update dependencies in our CI, where all those different lock files come from, and what the CI does; and I think adding this CLI to the CI would complicate things even more.

I know this sounds like I'm a grumpy old man, but not looking at the development for a few months, coming back, and noticing you don't understand a thing, is not a good thing, and I used to work quite a bit on our CI side. I'm not sure where things are documented, and the PRs people open to update deps don't mention how they're done. We have a discoverability issue there.

I don't necessarily understand why we need new shiny things when the old tools work brilliantly (aka `Makefile`), which has the benefit that it contains scripts which you can basically copy/paste and customize in your shell. Whereas extracting a shell script from a python script is going to be impossible as soon as things get complicated.

For new contributors:
- CLI has the benefit that they can copy/paste commands from docs and run things, and we can have complex logic behind those commands to hide them away.
- At the same time, it hides away what's being done in the background. I think a value for first time contributors is for them to learn `pytest`, `flake8`, `isort`, `black`, build process, pre-commit hooks, etc.

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.

An alternative for some of the issues we have, is to have bots which parse the output of our CI and comment on PRs with clear instructions on how a contributor needs to fix them. Example: https://github.com/conda-forge/skops-feedstock/pull/1#issuecomment-1287938702

![image](https://user-images.githubusercontent.com/1663864/199941197-4677a7ef-2c4d-4bd3-9628-a1f0c8673a49.png)


cc @scikit-learn/core-devs

Also cc @reshamas , @cmarmo , since I value their input in such matters as they might have a better idea of what our average contributors might need and want to have.

Labels: RFC, workflow