MAINT: Replace find_common_types

[eendebakpt]

What does this implement/fix?

The np.find_common_type method is deprecated within numpy. See numpy/numpy#21703 and numpy/numpy#21742.
This PR was triggered because np.find_common_type is one of performance bottlenecks inside the scipy.stats.rv_continuous.

This PR replaces the np.find_common_type with np.results_type or np.promote_type. These alternatives are both faster and maintained.

Additional information

Microbenchmark results

In [45]: runcell(1, '/home/eendebakpt/sympy/sympy/geometry/tests/untitled13.py')
float64
9.25 µs ± 672 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [46]: import numpy as np
    ...: from numpy.core.numerictypes import find_common_type
    ...: from numpy import promote_types , result_type
    ...: 
    ...: array_types = [np.dtype('float64'), np.dtype('float64')]
    ...: 
    ...: print(find_common_type(array_types, []))
    ...: %timeit find_common_type(array_types, [])
float64
8.62 µs ± 234 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [47]: print(promote_types(*array_types))
    ...: %timeit promote_types(*array_types)
float64
117 ns ± 2.63 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

[seberg]

In theory, this can change the result in some cases, but in practice I can't think of a way to make it fail when the first part is [int]...
(in that case u.dtype == longdouble is honored. A change would happen there if the first part was a float/complex, where the longdouble would then be ignored.)

[perimosocordiae]

scipy.sparse changes look fine

[tupui]

LGTM, we have some approvals and CI is happy. In it goes. Thank you @eendebakpt et al.!