lib/msun: Cleanup after $FreeBSD$ removal

Remove no longer needed explicit inclusion of sys/cdefs.h.

PR: 276669
MFC after: 1 week

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Add a macro nan_mix() and use it to get NaN results that are (bitwise)
independent of the precision in most cases. This is mainly to simplify
checking for errors. r176266 did this for e_pow[f].c using a less
refined expression that often didn't work. r176276 fixes an error in
the log message for r176266. The main refinement is to always expand
to long double precision. See old log messages (especially these 2)
and the comment on the macro for more general details.

Specific details:
- using nan_mix() consistently for the new and old pow*() functions was
the only thing needed to make my consistency test for powl() vs pow()
pass on amd64.

- catrig[fl].c already had all the refinements, but open-coded.

- e_atan2[fl].c, e_fmod[fl].c and s_remquo[fl] only had primitive NaN
mixing.

- e_hypot[fl].c already had a different refined version of r176266. Refine
this further. nan_mix() is not directly usable here since we want to
clear the sign bit.

- e_remainder[f].c already had an earlier version of r176266.

- s_ccosh[f].c,/s_csinh[f].c already had a version equivalent to r176266.
Refine this further. nan_mix() is not directly usable here since the
expression has to handle some non-NaN cases.

- s_csqrt.[fl]: the mixing was special and mostly wrong. Partially fix the
special version.

- s_ctanh[f].c already had a version of r176266.

lib/msun: avoid referring to broken LDBL_MAX

LDBL_MAX is broken on i386:
https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html

Gcc has produced +Infinity for LDBL_MAX on i386 and amd64 with -m32
for some time, and newer versions of gcc are now warning that the
"floating constant exceeds range of 'long double'". Avoid this by
referring to proxy values instead.

Reviewed by: bde
Approved by: markj (mentor)
Sponsored by: Dell EMC Isilon

Revert r322418, LDBL_MAX_EXP unsuitable for macro pasting on some arches

Either need a different way to spell HALF_LDBL_MAX, or a different way
to spell LDBL_MAX_EXP, or a different approach.

Reported by: ian

lib/msun: avoid referring to broken LDBL_MAX

LDBL_MAX is broken on i386:
https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html

Gcc has produced +Infinity for LDBL_MAX on i386 and amd64 with -m32
for some time, and newer versions of gcc are now warning that the
"floating constant exceeds range of 'long double'". Avoid this by
referring to half the value of LDBL_MAX instead.

Reviewed by: bde
Approved by: markj (mentor)
Sponsored by: Dell EMC Isilon

Silence a -Wunused warning about the junk variable being used to raise
an inexact floating point exception. The variable cannot be eliminated,
unfortunately, otherwise the desired addition triggering the exception
will be emitted neither by clang, nor by gcc.

Reviewed by: Steve Kargl, bde
MFC after: 3 days

Add casinl() cacosl() catanl() casinhl() cacoshl() catanhl() APIs to msun
to improve C11 conformance.

PR: 216850 216851 216852 216856 216857 216858
Submitted by: mmokhi
Reported by: sgk@troutmask.apl.washington.edu
Reviewed by: bde, mat, theraven
Approved by: bde (src committer), mat (mentor)
Differential Revision: https://reviews.freebsd.org/D9491