since x86 and m68k are the only archs with 80-bit long double and each
has mandatory endianness, select the variant via endianness.
differences are minor: apparently just byte order and representation
of infinities. the m68k format is not well-documented anywhere I could
find, so if other differences are found they may require additional
changes later.

The sign bit was not cleared before checking for 0 so -0.0
was misclassified as FP_SUBNORMAL instead of FP_ZERO.

previously the external definitions of these functions were omitted on
archs where long double is the same as double, since the code paths in
the math.h macros which would call them are unreachable. however, even
if they are unreachable, the definitions are still mandatory. omitting
them is invalid C, and in the case of a non-optimizing compiler, will
result in a link error.

apparently gnulib requires invalid long double representations
to be handled correctly in printf so we classify them according
to how the fpu treats them: bad inf is nan, bad nan is nan,
bad normal is nan and bad subnormal/zero is minimal normal

new ldshape union, ld128 support is kept, code that used the old
ldshape union was rewritten (IEEEl2bits union of freebsd libm is
not touched yet)

ld80 __fpclassifyl no longer tries to handle invalid representation

this is silly, but it makes apps that read binary junk and interpret
it as ld80 "safer", and it gets gnulib to stop replacing printf...

thanks to the hard work of Szabolcs Nagy (nsz), identifying the best
(from correctness and license standpoint) implementations from freebsd
and openbsd and cleaning them up! musl should now fully support c99
float and long double math functions, and has near-complete complex
math support. tgmath should also work (fully on gcc-compatible
compilers, and mostly on any c99 compiler).

based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from
nsz's libm git repo, with some additions (dummy versions of a few
missing long double complex functions, etc.) by me.

various cleanups still need to be made, including re-adding (if
they're correct) some asm functions that were dropped.

this should not be necessary - the invalid bit patterns cannot be
created except through type punning. however, some broken gnu software
is passing them to printf and triggering dangerous stack-smashing, so
let's catch them anyway...