Fix ORANGE bounding box bumping to be consistent with tracking tolerances

[sethrj]

Particles in EMPIRE were getting lost while crossing the $z=0$ plane because they didn't register as being in the bounding box on the other side. This is because nextafter(0f, -inff) gives a value of -1e-45f whereas it's reasonable and expected for the particles themselves to be bumped on $O(10^{-12})$. We should be using the same bump behavior as in the BumpCalculator: each box coordinate is pushed outward by max(abs_tol, rel_tol * fabs(value)).

Instead of bumping outward by the width, we bump outward by the local value, since semi-infinite bounding boxes are not uncommon.

[sethrj]

@tmdelellis @elliottbiondo Looks like you really have to use std::nextafter after all: the universe unit test was failing because the default ORANGE tolerance (1e-8) was bumping O(1) values and then being rounded back to zero during truncation.

With the last implementation we are doing the following:

1. We expand the bounding box to past the point that any particle can be bumped (or end up logically crossing when machine precision gets thrown in the mix).
2. We truncate that double-precision box to single-precision.
3. We expand the single-precision box by one ULP, ensuring it fully encloses the bumped double-precision bounding box.

This gives correct absolute rounds near the small values, and correct values for relative erros.