Fix ecvt/fcvt issues w.r.t. value==0 and ndigit==0

[GabrielRavier]

Before this commit, cosmopolitan had some issues with handling arguments
of 0 and signs, such as returning an incorrect sign when the input value
== -0.0, and incorrectly handling ndigit == 0 on fcvt (ndigit determines
the amount of digits after the radix character on fcvt, thus the parts
before it still must be outputted before fcvt's job is completely done).

This patch fixes these issues, and adds tests with corresponding inputs.

[jart]

These functions aren't part of the C standard anymore. I agree it's worth it to have them be more correct and consistent with glibc. What you discovered is also a bug in OpenbSD. I recommend sending them a patch, so they'll know Cosmo is helping them. It's also a bug in Apple Libc. OTOH FreeBSD has removed these APIs.

[GabrielRavier]

w.r.t. glibc consistency I was actually only really trying to make changes that I could back up with a reasonable interpretation of POSIX-2004 (i.e. discarding cases that are either deliberately implementation defined (e.g. *decpt can be 0 or 1 when value == 0) or UB (e.g. ndigit < 0 seems to be UB)) but if you think it'd be better to try to make it behave exactly like glibc I could also do that (well, technically, exactly like glibc would be going clearly too far though, given glibc's implementation is actually buggy in some respects: https://sourceware.org/bugzilla/show_bug.cgi?id=29556, but ofc a few things could still be realistically be done to make it really close)

[GabrielRavier]

I'll also try to make a bug report to OpenBSD (though that'll take a bit given I'll want to setup an OpenBSD VM to do it properly) but do you know how to report bugs to Apple for libc at all ? (if there's even a way to do that, especially given I don't have any Apple computer in the first place...)