abs(-0.0) returns -0.0 instead of 0.0, and math.fabs(-0.0) does the
same. Both come from the idiom (x < 0) ? -x : x. Since -0.0 < 0 is
false, the negative zero is returned unchanged.
The idiom appears twice, once in dmath_fabs and once open-coded in
float__abs__. Fix dmath_fabs by clearing the sign bit, the same way
dmath_copysign just above it works, and make float__abs__ call the
shared helper instead of repeating the comparison.
abs(-0.0) == 0.0 is true even with the bug, because -0.0 == 0.0 under
IEEE 754, so the added tests compare str(...) to check the sign.
zfill writes the padding zeros before the whole string, so a leading
+ or - ends up in the middle of the result instead of staying in front.
For example "-5".zfill(4) gave '00-5' where CPython gives '-005'.
CPython inserts the padding after the sign character, and the sign
counts toward the requested width. Write the sign first, then the
zeros, then the rest of the string. delta is still computed before
this, so the total length is unchanged.
The existing tests only covered unsigned strings, which is why this
went unnoticed. Added three asserts alongside them.
