Add sample weights to Nearest Neighbors classifiers

### Describe the workflow you want to enable

Both `KNeighborsClassifier` and `RadiusNeighborsClassifier` support providing weights, determined as a function of the distances of the neighboring samples. However, it is not possible to provide `sample_weight`, usually given to `fit`. I.e., I'd like to be able to give a weight for each sample, regardless of its distance.

### Describe your proposed solution

A straightforward implementation would be, during prediction, to multiply the `weights` by the `sample_weight`. For example, in `KNeighborsClassifier.predict_proba` it would look something like:
```python
if self.sample_weight_ is not None:
    weights *= self.sample_weight_[neigh_ind]
```
after having set `self.sample_weight_` during `fit`.

### Describe alternatives you've considered, if relevant

One could argue, that in the case of `KNeighborsClassifier` (as opposed to `RadiusNeighborsClassifier`), in addition to the weighing proposed above, the number of neighbors `n_neighbors` itself should be interpreted as "the number of effective samples after weighing". That means that for each query sample, we'd like to query $k$ nearest neighbors, such that $k$ is the minimal integer satisfying 
$$\sum_{i=0}^{k-1} w_i \ge n$$
where $w_i$ is the weight for the $i$-th nearest neighbor and $n$ is `n_neighbors`.

This is more tricky to implement, as we don't know in advance how many neighbors to query, and the number is different for each sample. A reasonable compromise would be to query "a bit more" (maybe double?) neighbors than `n_neighbors`, and then take only as many neighbors as needed for each sample. 

Another complication is that there can be a situation in which all queried neighbors are not enough to satisfy the condition. This should be handled similarly to the case in which (in the current implementation) `n_neighbors` is larger than the number of training samples, and raise a `ValueError`.

### Additional context

_No response_

COMMENT:
Hey there @cr-assafbendavid, thanks for opening an issue! There are a few things which make moving forwards on this a bit difficult:
1. We try to preserve the semantics of `sample_weights` as being equivalent to the "multiplicity" of points -- 
i.e. weights `[2, 1, 3]` would be equivalent to cloning the first point twice, and the final point thrice. The proposed solutions stray from this interpretation
2. The your primary proposed solution is also technically currently achievable by passing your own custom weight function. Note that by default `weights` are computed as either uniform weights, or inverse-distances, both of which would be readily available to your custom function. 
3. _Even if we did choose to stray_ from `sample_weights` semantics, this would also greatly benefit from a rigorous, peer-reviewed and well-received research paper to suggest a "canonical" solution, otherwise there's no real way of us knowing the "correct" or at least "best" way to _actually_ implement the sample weights.

I'm going to go ahead and close this for now, but please feel free to continue the discussion and ping me if you have any questions or concerns regarding this -- thanks :)

Labels: New Feature, wontfix