Simplify/Fix Adaptivity for Small Errors or no CFL

[Steven-Roberts]

The TINY parameter used in the controllers could cause an error overestimation, particularly for the first step.

[drreynolds]

I am not expert on how robustly various architectures/compilers work with infinity. I'd like to see this PR pass all possible regression tests on all architectures before approving, but if infinity is handled correctly everywhere, then I would approve of these changes.

As another option, we could use the largest/smallest representable floating point numbers in the given precision to avoid having to do arithmetic with infinity.

[Steven-Roberts]

The behavior of pow, abs, min, max, and other functions for inf/nan is specified by the C standard, so I'm not too worried about that. I think a unit test where the error is 0 is warranted to double check. The standard only specifies that pow(0, 0) may cause a domain error (and doesn't even specify what the value could be), and pow(0, y) can cause floating point exceptions for certain y. I think I'll need to handle that more carefully in the controller.

[Steven-Roberts]

After considering the edge cases around pow(0,0), i.e., when there's no local error and a controller exponent is 0, it turns out to be benign. The C standard specifies pow(x,0)=1 for all x, and there's no undefined behavior. The test I added seems to support this for some limited cases.

[gardner48]

The recent updates look good, once the CI is passing and the TODO is addressed I think this will be good to merge