It turns out the computation we did in the non-negative case also
works for the negative case. The proof relies on elementary
properties of the two's complement representation.

I don't know how I never saw this before. To make things worse, it
seems that Kotlin and J2CL knew all along, and I never realized
when skimming through their implementations either.

Since conversions of signed longs to doubles is in fact no more
expensive than the unsigned longs, we can take shorter paths for
values that fit in the *signed* safe range.

This applies to the conversions to string (including in the
javalib) and to float.

TODO: Check the case where the divisor is >= 2^62.
TODO: Write down the proof.

Now that the worst case isn't so bad anymore, we remove the fast
paths for small values of the numerator.

It does make them slower. However, it also makes division more
predictable: the time is now dependent only on the divisor, which
should be more stable in most applications. It also reduces the
overall code size.