the new code uses that for all real |x| in [0x1p-999,0x1p999]

  y = (float)x

is the same as

  r = (double)x
  t = x - r
  if (t!=0 && r.bits%2==0)
    r.bits += (r<0)==(t<0) ? 1 : -1
  y = (float)r

in all rounding modes, with the same fenv effects.
this can be interpreted as a round to odd adjustment[1].
in fmaf t is computed with a fast2sum variant.

- optimized common case.
- implicit uflow handling instead of fenv calls.
- no fegetround check.
- no api calls on hf targets.
- fixed missed uflow on targets that signal it before rounding:
    fmaf(-0x1p-100f, 0x1p-100f, 0x1p-126f)
- removed freebsd code references and comments.
- fmaf.o code size vs before the halfway subnormal fix:
    x86_64: 514 -> 210
    armhf:  304 -> 156 (v7 thumb, no vfma op)
    arm:    400 -> 348 (soft float, no fenv)

round to odd paper (suggested by Sergey Davidoff):
[1] S. Boldo et al., Emulation of a FMA and correctly-rounded sums:
    proved algorithms using rounding to odd, 2008

inexact halfway cases were not handled correctly for subnormals

  fmaf(0x20201p-92f, 0x1fe01p-92f, 0x1p-130f)
  = (float)(0x1p-130 + 0x1.000000004p-150)

was rounded to 0x1.00001p-130 first in double precision, then to
0x1p-130 in the float subnormal range instead of 0x1.00002p-130.

this is a minimal fix of the halfway check.

Reported-by: Sergey Davidoff <shnatsel@gmail.com>

expl asm special cased |x|>=16384 and used 2^trunc(x) then,
but this was wrong for x<=-16384 when 2^trunc(x) doesn't
underflow to 0. fixed by bumping the threshold up to 32768.

Reported-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>

when x<0 and y is an odd int then powl is computed for -x first
then negated at the end. some overflow cases missed the negation:

  powl(-1.5, 50001)
  powl(-0.5, 50001)
  powl(-0x1p-16444L, -1)

returned inf, 0 and inf instead of the negated values.

Reported-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>

acosh(-0x1.8p15) returned -3.7534177368329567 instead of nan.

the same issue got fixed for acoshf and acoshl in commits
c4c38e6364323b6d83ba3428464e19987b981d7a and
6d10102709df4bc966d2846c1c45cd667e5048e5 here we follow the latter.

reported by Paul Zimmermann.

LDBL_* macros were not defined in logbl.

the code happens to be correct without them, but when the long double
format matches double the intention was to tail call logb.

the comment does not match the required or actual behavior when x<0
and y is not an integer. while it could be corrected, the role of
comments here is to tell about characteristics unique to the
implementation, not to restate the requirements of the standard, so
just removing it seems best.

if x!=0, y!=0, z==0 then

  fma(x,y,z) == x*y

in all rounding modes, while adding z can ruin the sign of 0 if x*y
rounds to -0.

These are identical to riscv64.