Do not call __nan in scalb functions.

Do not call __nan in scalb functions.

When libm functions return a NaN: if it is for NaN input, it should be
computed from that input (e.g. adding it to itself), so that payloads
are propagated and signaling NaNs quieted, while if it is for non-NaN
input, it should be produced by a computation such as
(x - x) / (x - x), which raises "invalid" at the same time as
producing an appropriate NaN, so avoiding any need for a call to
feraiseexcept.

Various libm functions, however, call __nan ("") (or __nanf or __nanl)
to determine the NaN to return, together with using feraiseexcept
(FE_INVALID) to raise the exception.  sysdeps/generic/math_private.h
has an optimization for those functions with constant "" argument so
this doesn't actually involve a call to the __nan function, but it is
still not the preferred approach for producing NaNs.  (The optimized
code also always uses the NAN macro, i.e. produces a default NaN for
float converted to whatever the target type is, and on some
architectures that may not be the same as the preferred default NaN
for double or long double.)

This patch fixes the scalb functions to use the conventional method of
generating NaNs and raising "invalid" with an appropriate
computation.  (Most instances of this issue are in the complex
functions, where it can more readily be fixed once they have been made
type-generic and so only a third as many places need fixing.  Some of
the complex functions use __nan ("") + __nan (""), where the addition
serves no purpose whatsoever.)

Tested for x86_64 and x86.

	* math/e_scalb.c: Do not include <fenv.h>.
	(invalid_fn): Do calculation resulting in NaN instead of raising
	FE_INVALID and returning a NaN explicitly.
	* math/e_scalbf.c: Do not include <fenv.h>.
	(invalid_fn): Do calculation resulting in NaN instead of raising
	FE_INVALID and returning a NaN explicitly.
	* math/e_scalbl.c: Do not include <fenv.h>.
	(invalid_fn): Do calculation resulting in NaN instead of raising
	FE_INVALID and returning a NaN explicitly.