`make_dense_tree()` with `angular=True` can segfault on poorly-behaved datasets

Minimal(ish) code to reproduce (I have tested this particular example with Python 3.9.16, numba 0.56.4, pynndescent 0.5.8 on ARM macOS, but I don't think the environment should matter much):

import numpy as np
from pynndescent.rp_trees import make_dense_tree

X1 = np.array(
    [
        100.01764, 100.01883, 100.021, 100.02009, 100.01863, 100.01916, 100.01936, 100.0154,
        100.0147, 100.01754, 100.0152, 100.0174, 100.017204, 100.02037, 100.02076, 100.01631,
        100.016014, 100.02034, 100.01806, 100.01909, 100.015465, 100.01851, 100.02122, 100.020515,
        100.016495, 100.01948, 100.01732, 100.02095, 100.01737, 100.01559, 100.01755, 100.016914,
    ],
    dtype=np.float32,
).reshape((-1, 1))
X = np.concatenate([X1, np.full((32, 1), 100, dtype=np.float32)], axis=1)

rng_state = np.array([2483244587, 2980075795, 3249322652], dtype=np.int64)
make_dense_tree(X, rng_state, angular=True)

What seems to be happening is that floating point rounding errors can lead angular_random_projection_split() to always assign all points to one side of the split. If this happens before the maximum leaf size is reached, the tree function recurses infinitely and eventually overflows the stack. I haven't checked if the same is true for euclidean_random_projection_split(), but it's at least conceivable that it could happen there as well.

This is a pretty bad dataset, but something like it might reasonably show up as a subset of something larger, and it's not unlikely that all the problematic points would eventually all end up in the same leaf. It's probably not reasonable to expect high-quality neighbors on this data, but it shouldn't cause a crash.

A few possibilities for fixing this:

I haven't been able to get a segfault to happen if I increase EPS to 1e-5. However, it seems that even with fairly large values of epsilon, it is still possible that the split function assigns all points to one side, which would not happen with exact arithmetic (since at least the left and right vectors should be assigned to opposite sides).
I also haven't been able to get a segfault to happen if I remove the step normalizing hyperplane_vector. With exact arithmetic this wouldn't change the split assignments, but I'm not sure if this makes the procedure more or less numerically stable in general.
The split function could explicitly check whether the split it produces is trivial, and if so, produce a new split randomly (or at least assign left and right to the appropriate sides).
The tree generation could have a recursion depth limit which, when hit, causes it to give up despite not having reached the target leaf size.

I can put together a PR for one or more of these if you let me know what solutions are preferred. Thanks!

lmcinnes / pynndescent

`make_dense_tree()` with `angular=True` can segfault on poorly-behaved datasets #209