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:
One motivation for not keeping both for too long is that currently adding a new cython extension requires to duplicate the work and increases the maintenance burden.

> 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.

One thing that I can think of is compilation with non default compilers that have their own OpenMP flags, like intel's [dpc++ compiler](https://www.intel.com/content/www/us/en/developer/tools/oneapi/dpc-compiler.html). The helper we have to set the appropriate flags is used when building using setuptools but not when building with meson. But I'm not even sure it's still working cause we've not been testing it for a while. And anyway if the need comes, we can try to fix it in sklearn or open an issue in meson anyway. So that wouldn't be a blocker imo.

Labels: Build / CI, RFC