op.c: Force shared hash key optimisation for existing COWs

If COW scalars are becoming more prevalent (they are), the hash key
optimisation will be less and less likely to kick in if it is skipped
for anything already SvIsCOW.

The assumption is that such a scalar is already a shared hash key sca-
lar.  That is not true for copy-on-write scalars made such by the new
mechanism that allows existing non-COW scalar to be upgraded to such.

The purpose of using shared hash keys scalars here is that the precom-
puted hash is already stored in the scalar (ok, it points to it indi-
rectly), speeding up hash lookup.

New COW scalars don’t have that and offer no speedup here.

So skip the optimisation only when the COW scalar is a shared hash
key scalar.

All of the above applies to methods as well.
Handle non-PV $_ in @INC filters

@INC filters (code refs returned by code refs in @INC) are given the
current line of code in $_ and can modify it.  The C code that invokes
the Perl filter is in pp_ctl.c:S_run_user_filter.  It was not taking
into account that $_ might not have a PV pointer when it is returned,
and so this could result in crashes or assertion failures.

This commit forces the scalar to be a string before returning it to
the lexer, unless it is undef.  If we force it to be a string when it
is undef, then existing tests start producing uninitialized warnings.

The logic is still faulty in places.  Subsequent commits will
address that.
Tying $_ in @INC filter

Crazy?  Probably.  But the existing code partially handles magic val-
ues already; it’s just buggy.  Also, the magic value could come from
another source filter that is not registered via @INC, and this is one
way to test that code path.
incfilter.t: squelch warning
Setting $_ to multiline glob in @INC filter

This commit corrects the one remaining code path in
pp_ctl.c:S_run_user_filter that was not handling non-PVs.

If we have to truncate $_ and keep the remainder in a cache (because
it has more than one line), we need to make sure we don’t assume it is
a PV when it comes to truncating it.

$ ./perl -Ilib -e '@INC = sub { sub { return 0 if $|--; $_ = *{"foo;\nbar"}; return 1 } }; do "foo"'
Assertion failed: (!isGV_with_GP(upstream)), function S_run_user_filter, file pp_ctl.c, line 5494.
Abort trap: 6
Handle magical return values from @INC filter

An @INC filter (a subroutined returned by a subroutine in @INC) could
be an lvalue sub that returns a magical scalar for the status.  We
need to account for that.

If we don’t call get-magic (FETCH), we’ll get the last value assigned
to or returned from that scalar.
pp_ctl.c:S_run_user_filter: remove GMAGICAL check

We have already called get-magic at this point, so SvOK will give
the right answer even for magical variables.  Concatenating it when
gmagical could give an uninitialised warning if it is undef, so
we don’t want to do that, as it would cause magical and non-mag-
ical undefs to behave differently.  I don’t know how to write a
test for this.
[Merge] Handle @INC filter return values better
Make SvPVbyte work on tied non-PV

The magic check came too late.  sv_utf8_downgrade does nothing if the
argument is not a PV.

So in the test added to svpv.t the returned string was in utf8,
not bytes.
Fix booleanness of regexps

I broke this when I stopped regexps from being POK in 5.18.
sv.c: Remove more ro exceptions that c72a4ee missed.
Modifying ${^OPEN} changes the value of $^H:

$ ./perl -le 'BEGIN { print $^H; ${^OPEN} = "a\0b"; print $^H}'
256
917760

So changing $^H back should change the value of ${^OPEN} back to undef, right?

$ ./perl -le 'BEGIN { ${^OPEN} = "a\0b"; $^H=256; print ${^OPEN}//"undef"}'
ab
$ ./perl -le 'BEGIN { ${^OPEN} = "a\0b"; $^H=256;}BEGIN{ print ${^OPEN}//"undef"}'
undef

Apparently you have to hop from one BEGIN block to another to see
the changes.

This happens because compile-time hints are stored in PL_hints (which
$^H sets) but ${^OPEN} looks in PL_compiling.cop_hints.  Setting
${^OPEN} sets both.  The contents of PL_hints are assigned to
PL_compiling.cop_hints at certain points (the start of a BEGIN block
sees the right value because newSTATEOP sets it), but the two are not
always kept in synch.

The smallest fix here is to have $^H set PL_compiling.cop_hints as
well as PL_hints, but the ultimate fix--to come later--is to merge the
two and stop storing hints in two different places.