for storage of NVs, use "IV in sv_u in head no-body trick" where possible

for storage of NVs, use "IV in sv_u in head no-body trick" where possible

This completes the goal of commit 7b2c381cf3 from 5.9.2/2005. 8 bytes are
saved on arena and 8 byte double is NV builds, and usually 32 bytes
on PURIFY/malloced bodies builds. (2 void *s/16 bytes for header+16 bytes
minimum malloc size on typical malloc schemes). long doubles can't use this
optimization. Also a hypothetical NV is 32 bit float on 32 bit pointer OS
Perl build would use this optimization. 64 bit IVs on 32 bit pointer OS
use this optimization.

Also fixed was a bad solution from ML post
"[PATCH] Free old_body in sv_upgrade, also with -DPURIFY" commit bc78644842
which made the old body freeing code in sv_upgrade not obey the
body_details table. By checking allocation size instead whether there is an
arena better determins if there there is a body to free, PURIFY or not.
Note the upper SV types that are malloced/no arena are not upgradable so
this code wont be reached due to earlier croak, so there is no danger of
an arena ptr getting a free() done on it. This author doesnt have access
to PURIFY.

Also remove padding from body_details struct. On Win64, this struct
was 16 bytes, in format of U8 U8 U8 PAD1BYTE U32 U64. On Win32 it was
12 bytes long, in format of U8 U8 U8 PAD1BYTE U32 U32. Now on compilers
(such as VC) that allow 1 byte C bitfields (non-standard extension to C),
the struct is always 8 bytes long. I can't imagine an arena being >4GB on
64 bit perl.