Don’t sv_force_normal in mg.c:S_save_magic

This was added to make SvREADONLY_off safe.  (I think read-only is
turned off during magic so the magic scalar itself can be set without
the sv_set* functions getting upset.)  Since SvREADONLY doesn’t mean
read-only for COWs, we don’t actually need to do sv_force_normal, but
can simply skip SvREADONLY_off for COWs.

By leaving it to sv_set* functions to do sv_force_normal, we avoid
having to copy the string buffer if it is just going to be thrown away
anyway.  S_save_magic can’t know whether the scalar will actually be
overwritten, so it has to copy the buffer.
sv.c: No need to de-COW COWs on upgrade

I’ve taken the conservative approach of still de-COWing COWs for reg-
exps and anything above.  I’m not confident that it would be safe
for those.
Fix assertion failure with $float = $regexp assignment

Commit b9ad13acb3 caused case SVt_REGEXP in sv_upgrade to fall
through to the assertions under case SVt_PVIV that are not relevant to
SVt_REGEXP.

We should really be setting the FAKE flag when actually making a sca-
lar a regexp, rather than in sv_upgrade.  (I will probably need it
there in future commits, too, since it really should be possible for
SVt_PVLVs to hold regular expressions.)
Stop regexp assignment from clobbering magic

$ perl5.10.0 -le '$1 = ${qr||}; print "ok"'
Modification of a read-only value attempted at -e line 1.
$ perl5.12.0 -le '$1 = ${qr||}; print "ok"'
ok

Wonderful!

It can also cause blessings to be lost, or so I thought:

sub curse {
  for my $obj ( ${$_[0]} ) {
    my $save = $obj;
    $obj = ${qr||};
    $obj = $save;
  }
}
$y = bless \$x;
print $y, "\n"; # main=SCALAR(0x825b70)
curse $y;
print $y, "\n"; # Bus error

The OBJECT flag gets left on, but SvSTASH is null.

Commit b9ad13acb set SvSTASH to null after copying the regexp struct.
Commit 703c388dc did the same with SvMAGIC.  In both cases, this was
to avoid bugs involving magic and blessings being copied by = which
should not happen.  But both changes caused other bugs.

Three months later, 6e1287864cd changed the order of the struct, such
that SvMAGIC and SvSTASH are no longer copied from the parent regexp,
rendering the aforementioned changes no longer necessary.
sv.c: !SvLEN does not mean undefined

There are various SvPOKp(sv) && SvLEN(sv) checks in numeric
conversion routines in sv.c, which date back to perl 1.  (See
<http://perl5.git.perl.org/perl.git/blob/8d063cd8450e59e:/str.c#l89>.)
Back then it did not matter, as str->len (later SvLEN) was always set
when there was a PV.  It was not until perl 5.003_01 (1edc1566d5) that
we got the SvLEN==0 mechanism for PVs not owned by the scalar.  (I
don’t believe it was actually used till later, so when this became a
problem I don’t know--but that’s enough digging.)

A regexp returned by ${qr//} is POK but does not own its string.  This
means that nummifying a regexp will result in a uninitialized warning.

The SvLEN check is redundant and problematic, so I am removing it.
(This also means I can remove the sv_force_normal calls in the next
commit, since shared hash key scalars, which also have SvLEN==0 will
no longer need it to pass the SvLEN checks.)

This does mean, however, that SVt_REGEXP can reach code paths that
expect to be able to use Sv[IN]VX (not valid for regexps), so I actu-
ally have to check that the type != SVt_REGEXP as well.  We already
have code for handling fbm scalars (for which Sv[IN]VX fields are also
unusable), so we can send regexps through those paths.
sv.c: Remove redundant sv_force_normal calls from sv_2[iun]v

The previous commit made it possible to nummify a string whose SvLEN
is 0.  So we don’t need to run shared hash key scalars through
sv_force_normal before nummifying them.  We still need to run COW sca-
lars through sv_force_normal under PERL_OLD_COPY_ON_WRITE, as it uses
the IVX field for COW bookkeeping.  For simplicity’s sake, I’m not
bothering to distinguish shared hash keys scalars from other COW sca-
lars under PERL_OLD_COPY_ON_WRITE.
sv.c: Remove redundant Sv[INP]OK checks on fbm/regexps

These two code paths, sv_2iv and sv_2uv, used to be shared with gmag-
ical scalars in general, but now only apply to scalars that cannot
hold numeric values and are always SvPOK.
sv.c: Allow blessed cows

There is no reason kine should not receive blessings, too.
rmv a sv_2mortal and unused var in toke.c:Perl_yyerror_pvn

newSVpvn_flags is capable of mortalizing already, use that, is_utf8 is used
only once, waste of an auto var stack slot to calculate it so early,
instead create the flags arg to newSVpvn_flags at the point of usage.
flags param of yyerror_pvn will always be on the C stack.
yyerror->yyerror_pvn in toke.c:S_new_constant

Avoids a strlen.
Don’t skip tied EXISTS for negative array indices

This was broken in 5.14.0 for those cases where $NEGATIVE_INDICES is
not true:

sub TIEARRAY{bless[]};
sub FETCHSIZE { 50 }
sub EXISTS { print "does $_[1] exist?\n" }
tie @a, "";
exists $a[1];
exists $a[-1];
$NEGATIVE_INDICES=1;
exists $a[-1];

$ pbpaste|perl5.12.0
does 1 exist?
does 49 exist?
does -1 exist?
$ pbpaste|perl5.14.0
does 1 exist?
does -1 exist?

This was broken by 54a4274e3c.
Don’t crash with $tied[-1] when array is tied to non-obj

The code for checking to see whether $NEGATIVE_INDICES is defined in
the tie package was very fragile, and was repeated four times.