MFC r354255:

Add __isnan()/__isnanf() aliases for compatibility with glibc and CUDA

Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:

In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^

CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().

To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.

Reported by: arrowd
PR: 241550

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Add an explanatory comment to lib/libc/gen/isnan.c about the fix to make
static linking with libc and libm work.

Requested by: jilles
MFC after: 1 week
X-MFC-With: 242879

Only define isnan, isnanf, __isnan and __isnanf in libc.so, not in
libc.a and libc_p.a. In addition, define isnan in libm.a and libm_p.a,
but not in libm.so.

This makes it possible to statically link executables using both isnan
and isnanf with libc and libm.

Tested by: kargl
MFC after: 1 week

Remove __isnanl() to avoid conflicting with the same function in libm.
__isnan() and __isnanf() must remain in libc for hysterical raisins.
On the other hand, __isnanl() must live in libm because libm uses it
internally and can't depend on older versions of libc to provide it.
Fortunately, we don't need __isnanl() in both libraries.

Prodded by: ale
PR: 71698
MT5 candidate

Implement the classification macros isfinite(), isinf(), isnan(), and
isnormal() the hard way, rather than relying on fpclassify(). This is
a lose in the sense that we need a total of 12 functions, but it is
necessary for binary compatibility because we have never bumped libm's
major version number. In particular, isinf(), isnan(), and isnanf()
were BSD libc functions before they were C99 macros, so we can't
reimplement them in terms of fpclassify() without adding a dependency
on libc.so.5. I have tried to arrange things so that programs that
could be compiled in FreeBSD 4.X will generate the same external
references when compiled in 5.X. At the same time, the new macros
should remain C99-compliant.

The isinf() and isnan() functions remain in libc for historical
reasons; however, I have moved the functions that implement the macros
isfinite() and isnormal() to libm where they belong. Moreover,
half a dozen MD versions of isinf() and isnan() have been replaced
with MI versions that work equally well.

Prodded by: kris