RFC Remove setuptools-based build in scikit-learn 1.6

### Proposal 

I would be in favour of removing setuptools i.e. all `setup.py` files in 1.6. Meson is our main building tool for some time, teething issues have been found and fixed, and no major blocker issues have been found. We discussed this at the monthly developers meeting today and there did not seem to be any strong objections.

I asked on the Scipy Slack (see [message](https://scipy-community.slack.com/archives/C03JL2YGCNR/p17188505738275990) if you are on the Scipy Slack) and got this response from @rgommers:

> Now with also Matplotlib and others having switched over, I think you'd be safe with removing setup.py quickly. I am not aware of any blockers in any package that switched so far.

Some projects have removed `setup.py` already:
- scikit-image has remove `setup.py` in 0.20 released March 2023: https://github.com/scikit-image/scikit-image/pull/6738
- matplotlib has removed `setup.py` in 3.9 released May 16: https://github.com/matplotlib/matplotlib/pull/26621
- Numpy has removed `setup.py` in Numpy 2 released June 16: https://github.com/numpy/numpy/pull/24519

For local development, I am reasonably confident things should be fine:
- building with Meson has been merged 5 months ago (merged January 23) https://github.com/scikit-learn/scikit-learn/pull/28040 and I have been using Meson since then
- most of the developers have been using Meson day-to-day for 1-2 months+ (rough estimate)
- Meson has been presented as our "main building tool" for one month and a half: https://github.com/scikit-learn/scikit-learn/pull/29008 (merged May 13).

### Potential issues / things to think about

- OpenMP-specific quirk, From the discussion with @rgommers:
  > The one thing I can think of that's different in scikit-learn is OpenMP usage. Not sure if that required any special handling beyond linking to llvm-openmp and then running auditwheel & co?

  I can not think about OpenMP-specific issues but happy to hear other opinions. We have released wheels with Meson for 1.5 roughly one month ago, and it doesn't seem like there has been any issues.

- Linux distribution packaging may still rely on `setup.py`. I am certainly not a Linux packaging expert but it seems like they may not rely on `setup.py` much:
  - ArchLinux seems to use `python -m build` see [this](https://gitlab.archlinux.org/archlinux/packaging/packages/python-scikit-learn/-/blob/main/PKGBUILD?ref_type=heads)
  - Fedora `pyproject_wheel` is used in [this](https://src.fedoraproject.org/rpms/python-scikit-learn/blob/rawhide/f/python-scikit-learn.spec) which I think means `python -m pip wheel` from [this file](https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/pyproject_wheel.py)
  - Debian I am not sure, the [`rules`](https://salsa.debian.org/science-team/scikit-learn/-/blob/master/debian/rules?ref_type=heads) seems to use `python setup.py config` somewhere, but there is also some automatic build detection that should pick Meson IIUC https://wiki.debian.org/Python/Pybuild 
  - on this topic, let me ping people that are involved in Linux distribution packaging @mr-c @gspr @sergiopasra that I met in https://github.com/scikit-learn/scikit-learn/issues/27506.

- any other use case that I didn't think of and that may be using `setup.py`?

### Alternative more conservative option

If we are more comfortable with the more conservative, we could follow what Scipy has done i.e. rename `setup.py` to `_setup.py` and keep `_setup.py` as a fall-back for some time, maybe in 1.6, and remove it in scikit-learn 1.7.

@rgommers said on this:

> we did keep _setup.py as a backup for ~2 minor releases, because of the known conda-forge issue, and because our build is very complex and we were the very first package to shift over to Meson, so we weren't 100% sure what surprises we'd encounter. I think there were a few other Linux distros that stayed with setup.py for at least one release cycle, but I think mostly that was a "this is less work right now" than anything fundamental.

COMMENT:
There is https://github.com/scipy/scipy/issues/17075 about Intel compiler support in Scipy, this seems like there is some kind of support. Not sure about OpenMP detection, someone would need to try it out ... my feeling right now is we are amongst the first to test OpenMP with Meson in the Scientific Python ecosystem so there may be issues (maybe?).

Labels: Build / CI, RFC