`num` test failures beyond bit-for-bit differences with intrinsic math

If you try to build MESA with `USE_CRMATH = NO` in `utils/makefile_header`, some of the differences in `num`'s test results are surprisingly large. You'll need to skip `auto_diff`'s tests with `touch auto_diff/skip_test`.

e.g. for the Cash–Karp method, the expected output is
```
calculated 1 1.7633919298826672D+00
calculated 2 -8.3553976467637270D-01
```
whereas we get
```
calculated 1 1.7634625993645798D+00
calculated 2 -8.3545009921766566D-01
```
which differs already at the ~0.001 level. There are also various similarly large differences when calling the implicit solvers with numerical Jacobians (though differences seem to remain small with analytic Jacobians).

I'm personally not worried by differences within a few orders of magnitude of machine precision (say, <1e-10) but I don't understand why these are so different. There are very few calls to functions that are replaced by CRMATH and they seem to be confined to adjusting stepsizes anyway.

Start with utils/makefile_header and the num test suite, building with USE_CRMATH = NO; skip auto_diff tests with touch auto_diff/skip_test. Compare the Cash–Karp output and implicit-solver results with numerical versus analytic Jacobians. Done means identifying why the non-CRMATH differences exceed the expected tolerance and documenting or correcting the affected behavior.

Written by the indexing model from the issue text.