Migrate to `npt.assert_allclose`

[seanlaw]

According to the NumPy docs for npt.assert_almost_equal:

It is recommended to use one of assert_allclose, assert_array_almost_equal_nulp or assert_array_max_ulp instead of this function for more consistent floating point comparisons.

Perhaps, we should migrate our tests accordingly?

To Do List

• Each test file correctly replaces all uses of npt.assert_almost_equal with its equivalent npt.assert_allclose
• When rtol=0 for npt.assert_allclose, simply omit this paramter and value since this is the default
• Ensure that npt.assert_allclose(actual, desired) always has the stumpy computed value as "actual" and the naive computation as "desired"
• Use atol=1.5e-07 rather than atol=1.5*10**-07
• Eventually, replace the ugly 1.5*10**-config.STUMPY_TEST_PRECISION with config.STUMPY_TEST_PRECISION = 1.5e-07 (in config.py)
• Replace comp with cmp
• Rename naive outputs to ref_ and stumpy-computed outputs to cmp_ (applies to npt.assert_array_equal too)

[viknesh-ai]

Agreed ,assert_almost_equal only checks absolute tolerance (abs(actual-desired) < 1.510**-decimal), while assert_allclose combines relative + absolute (atol + rtolabs(desired)), so it's more meaningful for comparisons across varying magnitudes and matches what NumPy recommends.

I count 1283 call sites across 40 test files currently using assert_almost_equal (only 2 already use assert_allclose), so this is a fairly mechanical but wide-reaching change. Proposing two passes: first a straight swap to assert_allclose(a, b, atol=1.5*10**-decimal, rtol=0) everywhere, which preserves today's exact pass/fail behavior with no risk, then a follow-up pass to set meaningful rtol/atol case-by-case where a relative tolerance is actually the right thing to check (the rtol=1e-12, atol=1e-12 used in the #1174 MASS precision tests is a decent template for that). I can start on pass 1 if that approach sounds good to you.