Fix what appears to have been a thinko in the rounding of
floating-point printed representations. This fix prevents the code
from diverging with certain combinations of numbers and rounding
modes. An example that caused this problem:
(set! flonum-unparser-cutoff '(relative 4))
(/ (* 10e3 100e-15))
I'm not entirely convinced I understand the problem at this point; I
don't have a copy of the paper at hand to remind me how the printer
algorithm works. But the change fixes the bug, seems to work
correctly on other test cases, and matches what my partial
understanding says should be happening.