Replace HasDomain to enable multi-argument edge case and domain tests

[tgross35]

This also allows reusing the same generator logic between logspace tests and extensive tests, so comes with a nice bit of cleanup.

Changes:

• Make the generator part of CheckCtx since a Generator and CheckCtx are almost always passed together.
• Rename domain_logspace to spaced since this no longer only operates within a domain and we may want to handle integer spacing.
• Domain is now calculated at runtime rather than using traits, which is much easier to work with.
• With the above, domains for multidimensional functions are added.
• The extensive test generator code tests has been combined with the domain_logspace generator code. With this, the domain tests have just become a subset of extensive tests. These were renamed to "quickspace" since, technically, the extensive tests are also "domain" or "domain logspace" tests.
• Edge case generators now handle functions with multiple inputs.
• The test runners can be significantly cleaned up and deduplicated.

[tgross35]

The improved edge case tests are showing some inputs where our results differ from spec, which is a great thing.

thread 'musl_edge_case_fmax' panicked at crates/libm-test/tests/compare_built_musl.rs:26:51:
called `Result::unwrap()` on an `Err` value: 
    input:    (-0.0, 0.0) (0x8000000000000000, 0x0000000000000000)
    expected: 0.0                    0x0000000000000000
    actual:   -0.0                   0x8000000000000000

Caused by:
    mismatched signs -1.0 1.0

---- musl_edge_case_fmaxf stdout ----
EdgeCases Musl fmaxf arg 1/2: 86 edge cases
EdgeCases Musl fmaxf arg 2/2: 86 edge cases

thread 'musl_edge_case_fmaxf' panicked at crates/libm-test/tests/compare_built_musl.rs:26:51:
called `Result::unwrap()` on an `Err` value: 
    input:    (-0.0, 0.0) (0x80000000, 0x00000000)
    expected: 0.0                    0x00000000
    actual:   -0.0                   0x80000000

Caused by:
    mismatched signs -1.0 1.0

---- musl_edge_case_fmin stdout ----
EdgeCases Musl fmin arg 1/2: 86 edge cases
EdgeCases Musl fmin arg 2/2: 86 edge cases

thread 'musl_edge_case_fmin' panicked at crates/libm-test/tests/compare_built_musl.rs:26:51:
called `Result::unwrap()` on an `Err` value: 
    input:    (-0.0, 0.0) (0x8000000000000000, 0x0000000000000000)
    expected: -0.0                   0x8000000000000000
    actual:   0.0                    0x0000000000000000

Caused by:
    mismatched signs 1.0 -1.0


---- musl_edge_case_fminf stdout ----
EdgeCases Musl fminf arg 1/2: 86 edge cases
EdgeCases Musl fminf arg 2/2: 86 edge cases

thread 'musl_edge_case_fminf' panicked at crates/libm-test/tests/compare_built_musl.rs:26:51:
called `Result::unwrap()` on an `Err` value: 
    input:    (-0.0, 0.0) (0x80000000, 0x00000000)
    expected: -0.0                   0x80000000
    actual:   0.0                    0x00000000

Caused by:
    mismatched signs 1.0 -1.0

The C spec has a footnote: "Ideally, fmax would be sensitive to the sign of zero, for example fmax(−0.0, +0.0) would return +0; however, implementation in software might be impractical.", but based on a comment in our source for these functions, it sounds like IEEE may say something slightly different. Something to look into more, I can xfail these for now.

Edit: opened #439 to track this.

[tgross35]

This should be nearly done, I just need to double check the test count logic. Cc @beetrees since this PR interacts with your recent changes.

[tgross35]

Oh no, we have a buf in fma on i686? Happens on both i586 and i686:

---- mp_edge_case_fma stdout ----
EdgeCases Mpfr fma arg 1/3: 84 edge cases
EdgeCases Mpfr fma arg 2/3: 84 edge cases
EdgeCases Mpfr fma arg 3/3: 84 edge cases

thread 'mp_edge_case_fma' panicked at crates/libm-test/tests/multiprecision.rs:17:48:
called `Result::unwrap()` on an `Err` value: 
    input:    (0.999999999999999, 1.0000000000000013, 0.0) (0x3feffffffffffff7, 0x3ff0000000000006, 0x0000000000000000)
    expected: 1.0000000000000002     0x3ff0000000000001
    actual:   1.0000000000000004     0x3ff0000000000002

Caused by:
    ulp 1 > 0

[tgross35]

I need to cut down the CI runtime somehow. Time reporting from #441 should help figure out what is taking so long.

[tgross35]

It would probably be nice to somehow reduce the number of iterations that run for bessel functions, since that is the biggest chunk of CI time. And we are still not testing jn/yn because MPFR crashes (I still need to look into it more, I could just be doing something incorrectly). But a ~seven minute increase in CI time here is tolerable for much better coverage of edge cases.

#446 should eventually win some time back.