MAINT Remove all Cython, C and C++ compilations warnings

## Context

scikit-learn builds with Cython, C and C++ warnings (when building wheels or for when installing locally (for development)). There are several kinds of warnings, each kind having its own cause, solutions and mitigations.

### 🏷 Use of the deprecated NumPy API (via Cython) (`-Wcpp`)

Some Cython implementations might use old Cython idiomatic constructs or old symbols of NumPy directly via [NumPy's Cython API](https://github.com/cython/cython/blob/master/Cython/Includes/numpy/__init__.pxd) (generally used via `cnp` from `cimport numpy as cnp`) which are deprecated.

Examples of such symbols non-exhaustively involves:
 - the `cnp.ndarray`
 - some constants (see [this enum](https://github.com/cython/cython/blob/master/Cython/Includes/numpy/__init__.pxd#L127-L158) for instance)

Such warnings are not raised compiling Cython code, but are when compiling C and C++ code, generated by Cython (or even in standalone implementations using the NumPy C API directly).

🧰 Resolutions involves:
 - using newest Cython idiomatic constructs (notably memoryviews) and up-to-date symbols of NumPy via NumPy's Cython API
 - adding extensions in the `USE_NEWEST_NUMPY_C_API` list (so that it `#define` macros indicating not to use of old deprecated symbols from NumPy)
   https://github.com/scikit-learn/scikit-learn/blob/3e47fa91b6ed73f358105f2a1c6501e14f633bba/setup.py#L64-L70

- at least the following Cython extensions:
   - [x] `sklearn.cluster._dbscan_inner` #24881
   - [x] `sklearn.cluster._hierarchical_fast` #24914
   - [x] `sklearn.linear_model._sgd_fast` #24883
   - [x] `sklearn.utils.murmurhash` #24958
   - [x] `sklearn.ensemble._gradient_boosting` #25033
   - [x] `sklearn.manifold._utils` #24925
   - [x] `sklearn.neighbors._ball_tree` #24965
   - [x] `sklearn.neighbors._kd_tree` #24965
   - [x] `sklearn.linear_model._sag_fast` #24975
   - [x] `sklearn.svm._libsvm` #25064
   - [x] `sklearn.svm._liblinear` #25112
   - [x] `sklearn.svm._libsvm_sparse` https://github.com/scikit-learn/scikit-learn/pull/25064
   - [x] `sklearn.decomposition._online_lda_fast` #25020
   - [x] `sklearn.preprocessing._csr_polynomial_expansion` #25041
   - [x] `sklearn.tree._tree` #25540
   - [x] `sklearn.tree._criterion` (this one is hard) #25615
   - [x] `sklearn.utils.arrayfuncs` #25415
   - [x] `sklearn.neighbors._quad_tree` #25271
   - [x] `sklearn.utils.sparsefuncs_fast` #25244
   - [x] `sklearn.linear_model._cd_fast` #24895
   - [x] `sklearn.metrics._dist_metrics` #25702
   - [x] `sklearn.utils._seq_dataset`

<details>
<summary>Example of such warning in context</summary>


```
  building 'sklearn.cluster._dbscan_inner' extension
  creating /tmp/tmpuptw2_72.build-temp/sklearn/cluster
  gcc -pthread -B /home/jjerphan/.local/share/miniconda3/envs/sk/compiler_compat -DNDEBUG -fwrapv -O2 -Wall -fPIC -O2 -isystem /home/jjerphan/.local/share/miniconda3/envs/sk/include -fPIC -O2 -isystem /home/jjerphan/.local/share/miniconda3/envs/sk/include -fPIC -I/home/jjerphan/.local/share/miniconda3/envs/sk/lib/python3.11/site-packages/numpy/core/include -I/home/jjerphan/.local/share/miniconda3/envs/sk/include/python3.11 -c sklearn/cluster/_dbscan_inner.cpp -o /tmp/tmpuptw2_72.build-temp/sklearn/cluster/_dbscan_inner.o -O3 -fopenmp
  In file included from /home/jjerphan/.local/share/miniconda3/envs/sk/lib/python3.11/site-packages/numpy/core/include/numpy/ndarraytypes.h:1948,
                   from /home/jjerphan/.local/share/miniconda3/envs/sk/lib/python3.11/site-packages/numpy/core/include/numpy/ndarrayobject.h:12,
                   from /home/jjerphan/.local/share/miniconda3/envs/sk/lib/python3.11/site-packages/numpy/core/include/numpy/arrayobject.h:5,
                   from sklearn/cluster/_dbscan_inner.cpp:794:
  /home/jjerphan/.local/share/miniconda3/envs/sk/lib/python3.11/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
     17 | #warning "Using deprecated NumPy API, disable it with " \
        |  ^~~~~~~
```

</details>


### 🏷 Discarded `const`-qualification (`-Wdiscarded-qualifiers`)

In some implementation, some variables are being defined using  `const`-qualified variables.

For instance in C:

```c
// a is const-qualified and can't be modified then
const int a = 5;
// The const-qualification of a is discarded for the definition of b.
// b is not const-qualified and thus can be modified.
int b = a;

// Note that modifying b does not modify a.
// This would if a and b were pointers to objects
// (hence the reason for this kind of warning). 
```

While most of such definitions aren't harmful, some might be and compilers generally raise warning when the `const`-qualifications are discarded.

🧰 Resolutions involves:
 - `const` qualifying variables (like b) which currently aren't

<details>
<summary>Example of such warning in context</summary>

```
  sklearn/metrics/_dist_metrics.c: In function ‘__pyx_pf_7sklearn_7metrics_13_dist_metrics_14DistanceMetric_22_pairwise_sparse_dense’:
  sklearn/metrics/_dist_metrics.c:9143:29: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
   9143 |             __pyx_v_x2_data = ((&(*((__pyx_t_7sklearn_5utils_9_typedefs_DTYPE_t const  *) ( /* dim=1 */ ((char *) (((__pyx_t_7sklearn_5utils_9_typedefs_DTYPE_t const  *) ( /* dim=0 */ (__pyx_v_Y_data.data + __pyx_t_14 * __pyx_v_Y_data.strides[0]) )) + __pyx_t_18)) )))) + (__pyx_v_i2 * __pyx_v_n_features));
        |                             ^
```
</details>

### 🏷 Comparison on different integral-typed values (`Wsign-compare`) and integer overflow (`-Woverflow`)

Various integral dtypes (namely `(unsigned) {short,int,long}`,  an NumPy aliases i.e. `cnp.int*`, `size`, `Py_ssize_t`, other custom aliases in scikit-learn, etc.) are used in scikit-learn.

In Cython and C and C++ implementation, it is possible that binary operations (comparison, assignation, etc.) are applied on variable having different dtypes. Some of 

While such instructions aren't harmful, some might be and compilers generally raise warning in their presence.

🧰 Resolutions involves:
 - adapting type so that both values have the same one 
 - explicitly casting some variables' value to other temporary variables of the same type
 - reworking the use of fused types which generate specialised versions of functions for various combinations of types

<details>
<summary>Example of such warning in context</summary>

```
  sklearn/metrics/_pairwise_distances_reduction/_radius_neighbors.cpp: In function ‘void __pyx_f_7sklearn_7metrics_29_pairwise_distances_reduction_17_radius_neighbors_17RadiusNeighbors64_compute_exact_distances(__pyx_obj_7sklearn_7metrics_29_pairwise_distances_reduction_17_radius_neighbors_RadiusNeighbors64*)’:
  sklearn/metrics/_pairwise_distances_reduction/_radius_neighbors.cpp:6285:59: warning: comparison of integer expressions of different signedness: ‘__pyx_t_7sklearn_5utils_9_typedefs_ITYPE_t’ {aka ‘long int’} and ‘std::vector<long int>::size_type’ {aka ‘long unsigned int’} [-Wsign-compare]
   6285 |                             for (__pyx_t_6 = 0; __pyx_t_6 < __pyx_t_5; __pyx_t_6+=1) {
        |                                                 ~~~~~~~~~~^~~~~~~~~~~
```

</details>

### 🏷 Incompatible pointers types casts (`-Wincompatible-pointer-types`) (Difficulty level: :mage:)

On some Cython class, polymorphism implementations apparently cast to a incompatible pointers type.

This runs and works fine but this is a code smell which yet is to be inspected.

This problems mainly is present for the `DistanceMetric` and `BinaryTree` class hierarchies.

A similar problem has been reported in https://github.com/cython/cython/issues/2747.

🧰 Resolutions involves:
 - experimenting with the `@final` Cython decorator for `DistanceMetrics`' methods'
 - understanding how polymorphism is implemented
 - changing `DistanceMetrics`'' methods' signature 

<details>
<summary>Example of such warning in context</summary>

```
sklearn/metrics/_dist_metrics.c: In function ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_17EuclideanDistance_dist_csr’:
  sklearn/metrics/_dist_metrics.c:11320:88: warning: passing argument 1 of ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_17EuclideanDistance_rdist_csr’ from incompatible pointer type [-Wincompatible-pointer-types]
  11320 |   __pyx_t_1 = __pyx_f_7sklearn_7metrics_13_dist_metrics_17EuclideanDistance_rdist_csr(((struct __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric *)__pyx_v_self), __pyx_v_x1_data, __pyx_v_x1_indices, __pyx_v_x2_data, __pyx_v_x2_indices, __pyx_v_x1_start, __pyx_v_x1_end, __pyx_v_x2_start, __pyx_v_x2_end, __pyx_v_size); if (unlikely(__pyx_t_1 == ((__pyx_t_7sklearn_5utils_9_typedefs_DTYPE_t)-1.0))) __PYX_ERR(1, 927, __pyx_L1_error)
        |                                                                                       ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        |                                                                                        |
        |                                                                                        struct __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric *
  
```

</details>



## Proposed solution: treat one kind of warning for one file/extension at a time
- Only perform changes necessary to remove one kind of warning (🏷) for one file or one Cython extension at a time using information given in 🧰.
  - ⚠ It might not be possible to remove all warnings at once
  - ⚠ Changes might not be trivial or might necessitate adaption. In this case, please do explain the logic. 
- Create PRs for each warning with the following title:

  ```
  MAINT Remove `-Wkind` warnings when compiling `source_file.ext`
  ```
  where:
  - `kind` is the kind of warning (🏷), here represented as the formatted string in the subtitles, i.e. an element of (`cpp`, `incompatible-pointer-types`, `sign-compare`,`overflow`)
  - `source_file.ext` is the file being treated

- To be discussed among maintainers: once a kind of warnings as been entirely removed, turn on strict compilations compilation flags to raise error for this kind of warning.

## Miscellaneous 

### Example of compilation trace

Examples of warnings in their context stem from a verbose trace when building scikit-learn locally.

To see this full development installation trace (as of 2e481f114169396660f0051eee1bcf6bcddfd556), see [this gist](https://gist.github.com/jjerphan/8cfbb5349f5680856460ff80152ab69d).

### Filtering compilation trace

You can compile the whole project and filter the compilation trace for some module or source, using `grep` for instance. Note that `stderr` better be redirected to `stdout` to have all the information.

For instance, to perform this for `sklearn.linear_model._cd_fast`, you can running in the scikit-learn's worktree (using `-C` to have 6 surroundings lines in the context of matchings):

```
pip install --verbose --editable . 2>&1 | grep -C 3 "sklearn.linear_model._cd_fast"
```

COMMENT:
> Hi @jjerphan
> I was going through the _tree.pyx file and we have the following pattern
> https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/_tree.pyx#L94. To replace such cnp.ndarrays should we just replace them with objects or is there a better way?

Related to this, note that downstream code https://github.com/scikit-learn/scikit-learn/blob/7b13a8f120a6d67112b0f50a8834d65e2258f045/sklearn/tree/_splitter.pyx#L689 does not make any assumption on whether or not the X array is contiguous, or fortran. 

A one-time check does occur when trees are built, but does not necessarily always make `X` fortran (https://github.com/scikit-learn/scikit-learn/blob/7b13a8f120a6d67112b0f50a8834d65e2258f045/sklearn/tree/_tree.pyx#L108-L110).

If performance is the main concern, then I would be surprised if forcing `X` to be contiguous/fortran changes much. The argument for fortran would be that `X` sorts over samples (i.e. first dimensions). For contiguous, `X` also accesses random feature-columns (i.e. second dimension). Not much "intensive" looping over X being done. Perhaps there is a potential for performance improvement if `X` is forced into fortran during `_check_input`? But if not, it seems the rest of the scikit-learn mostly uses contiguous arrays, so for ease of maintainability that seems like the better option. 

I am not on the dev team tho, so not sure if there are issues with forcing X into one format or the other. If ppl agree w/ my analysis, I would propose the following:

1. create a branch for experimentation off of `main`
2. modify `_check_input` to always convert X to fortran
3. modify anywhere downstream where X is set to use `[::1, :]` fortran cython memoryview
4. run asv benchmarks on a computer not running anything else
5. repeat but in `_check_input` always convert X to contiguous

Labels: Easy, Build / CI, cython, Meta-issue, C/C++