PMC/SV structure access and layout

I've refactored the structure accesses in ponie further.

SvANY() and SvREFCNT() are now RVALUES, with SvANY_set(), SvREFCNT_set() and
a PMC call for SvREFCNT()++/--. In theory it should be possible to provide
LVALUE SvANY() and SvREFCNT() for outside the perl core, but I'm not sure if
it's actually safe or worthwhile, and for now I'd like to see how much (if any)
CPAN code breaks because it's unduly intimate with the SV implementation.

I think that the SV access is now sufficiently abstracted that it should be
possible to do several things, such as

1: For SvNULL move the flags and refcount into the top level PMC, not have an
   SV head structure, and always return SvANY() as NULL
2: Merge the SV heads and bodies, so SvANY() is returned as pointing to the
   correct thing for the later macro accesses, but isn't actually a separate
   piece of memory
3: Make PL_sv_undef, PL_sv_no, PL_sv_yes and PL_sv_placeholder special
   PMC types derived from Perl5NULL that do different things with reference
   counts.
4: Likewise treat PL_mess_sv specially.


More serious restructuring and complete abstraction of SV types still requires

1: Moving the reference count out somewhere else (or getting full GC working)
2: Moving sv_replace into the PMC code
3: Moving sv_unglob into the PMC code
4: Moving any other users of things like Ponie_P_NEWRV_HACK into the PMC code
5: Moving S_new_sv and S_del_sv there.

at which point I think that the perl core is completely agnostic to how
memory is allocated, *and* the individual PMC classes can be refactored
independent of each other.

Nicholas Clark