Introduce SIMD intrinsics for `_dist_metrics.pyx`

# Context
Pairwise distance computation is an essential part of many estimators in scikit-learn, and can take up a significant portion of run time in certain workflows. I believe that we may achieve significant performance gains in several (perhaps most) distance metric implementations by leveraging SIMD intrinsics.

# Proof of Concept

I built a quick proof of concept just to see what kinds of performance gains we could observe with a potentially-naive implementation of SIMD intrinsics. I chose to optimize the `ManhattanDistance.dist` function. This implementation uses intrinsics found in `SSE{1,2,3}`. To ensure that the instructions are supported, it checks for the presence of the `SSE3`  instruction set (`SSE3` implies `SSE{1,2}`) and provides the optimized implementation if so. Otherwise it provides a dummy implementation just to appease Cython, and the main function falls back to the current implementation on `main`. Note that on most modern hardware, support for `SSE3` is a reasonable expectation (indeed numpy assumes it is always present when optimization is enabled). For the specific implementation referred to here, please take a look at this PR: https://github.com/Micky774/scikit-learn/pull/11

Note that the full benefit of the intrinsics are gained when compiling with `-march="native"`, however the benefit is still significant when compiling with `-march="nocona"`, as is often default (e.g when following the scikit-learn development instructions on linux).

# Benchmarks
The following benchmarks were produced by this gist: https://gist.github.com/Micky774/567a5fa199c05d90c4c08625b077840e

### **Summary: The SIMD implementations are ~2x faster than the current implementation for `float32` and 1.5x faster for `float64`.**

<details>
<summary>Plots</summary>

![f2b1f1e8-59b0-4ec5-b91c-fe1d19abd9ec](https://user-images.githubusercontent.com/34613774/228374474-99ee13b3-228d-4c53-9dcc-3a8f8b639a9f.png)
</details>

# Discussion
I haven't looked too deeply into this yet, as first I wanted to see whether there was interest in the venture. I would love to hear what the other maintainers' thoughts are regarding exploring this route in a bit more detail. Obviously SIMD implementations will bring with them added complexity, but the performance gains are pretty compelling. In my opinion, the tradeoff is worth it.

CC: @scikit-learn/core-devs

COMMENT:
I think Cython is still a good compromise and still is the best short- and medium-term solution for scikit-learn IMO. The more we advance the more we are facing limitations with Cython as a language. Beyond problems solved with workarounds based on undocumented features or aspect of Cython, examples of limitation the team in this regard faced are:
 - costly abstraction and method dispatch overhead (e.g. #25044 #25170 #25306)
 - lack of safeness at runtime (e.g. #25484 #25584)
 - lack of idioms to support various data type in hierarchy of classes (e.g. #15474 #23865)

After having spent several thousand of hours reading, writing Cython code, and reading Cython's source code trying to contribute to the project, I can say that:
 - I like Cython for:
    - its concision
    - its learning curve thanks to interactive mode in Jupyter (I am probably biased for having programmed in C or C++ before)
    - the presence of interfaces to BLAS in SciPy which removes some burden from scikit-learn maintainers' life :heart: 
 
 - I do not like Cython for:
    - the lack of idioms for coming up flexible design with reliable and safe execution
    - the lack of a clear and unified documentation
    - paths and experience for contributing to Cython (PyRex predates PEP-8, a lot of complexity, unfortunate small bus-factor, etc.)
    - the small of developers' (and thus reviewers' pool) which might make authors and reviewers wait and perform context switches over months, making motivation fade quickly

Still, if we were to reconsider Cython over alternatives, I think we might need to perform before hand qualitative analysis, e.g. For an alternative X:
 - Can we enforce conventions?
 - Do people like developing using X over Cython?
 - Is it compelling and convenient for people to learn and to express their ideas with X over Cython?
 - Is X properly documented and tooled?
 - Does X have other limitations?

We also might want perform an analysis backed on evidence-backed (e.g. ideally, can we reach optimal and safe execution on a prototype first without changing scikit-learn's UX and packaging?). This is not negligible work.

I think the plugin API might make experimenting easier in this regards. :+1:

Labels: Enhancement, Needs Decision, cython