Improve handling of large values by inverse hyperbolic and trigonometric functions

[antonwolfy]

The dpnp.tensor.acosh function was returning incorrect results (infinity) for complex numbers with large negative real parts (see #2924).

The issue was caused by the threshold used 1/epsilon to decide when to switch from acos in SYCL's experimental complex extension (exprm_ns::acos()) to a log-based formula.
The SYCL exprm_ns::acos() returns incorrect results for large negative real parts, due to used formula z + sqrt(z² - 1), which leads to log(0) = -infinity.

The PR proposes to changed the threshold from 1/epsilon to sqrt(1/epsilon)/2 for all inverse trig/hyperbolic functions. This is the precision loss point where sqrt(z² ± 1) calculations become unstable.

Also the PR reduces code duplication by creating shared casinh(), casin(), catanh(), catan() functions in new complex_math.hpp header.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/pull/2928/index.html

[coveralls]

coverage: 78.239%. remained the same — update-inverse-trig-functions into master

[github-actions]

Array API standard conformance tests for dpnp=0.21.0dev0=py313h509198e_54 ran successfully.
Passed: 1356
Failed: 4
Skipped: 16

[ndgrigorian]

The PR proposes to changed the threshold from 1/epsilon to sqrt(1/epsilon)/2 for all inverse trig/hyperbolic functions. This is the precision loss point where sqrt(z² ± 1) calculations become unstable.

should this be filed as an issue with DPC++ compiler? Since most implementations should have logic to prevent overflow/infs in such cases