constant.pm: Make elements of list consts read-only

Now that Internals::SvREADONLY turns on the PADTMP flag for all the
elements, the read-only flag on the elements themselves will not
actually make the returned elements read-only, because PADTMPs get
copied in all cases where readonliness matters.  What this does is
prevent the original SV from being modified, allowing for more opti-
misations in perl’s internals (e.g., string buffers being stolen from
PADTMPs not marked read-only).

The order of the statements needs to be rearranged, otherwise we end
up setting the flag on a temporary copy of each element due to ‘for’.
op.c: Turn on read-only flag for folded constants

They are marked PADTMP, which causes them to be copied in any contexts
where readonliness makes a difference, so marking them as read-only
does not change the behaviour.  What it does is allow a future commit
to implement string swiping for PADTMPs.
Allow PADTMPs’ strings to be swiped

While copy-on-write does speed things up, it is not perfect.  Take
this snippet for example:

$a = "$b$c";
$a .= $d;

The concatenation operator on the rhs of the first line has its own
scalar that it reuses every time that operator is called (its target).
When the assignment happens, $a and that target share the same string
buffer, which is good, because we didn’t have to copy it.  But because
it is shared between two scalars, the concatenation on the second line
forces it to be copied.

While copy-on-write may be fast, string swiping surpasses it, because
it has no later bookkeeping overhead.  If we allow stealing targets’
strings, then $a = "$b$c" no longer causes $a to share the same string
buffer as the target; rather, $a steals that buffer and leaves the tar-
get undefined.  The result is that neither ‘$a =’ nor ‘$a .= $d’ needs
to copy any strings.  Only the "$b$c" will copy strings (unavoidably).

This commit only applies that to long strings, however.  This is why:

Simply swiping the string from any swipable TARG (which I tried at
first) resulted in a significant slowdown.  By swiping the string from
a TARG that is going to be reused (as opposed to a TEMP about to be
freed, which is where swipe was already happening), we force it to
allocate another string next time, greatly increasing the number
of malloc calls.  malloc overhead exceeds the overhead of copying
short strings.

I tried swiping TARGs for short strings only when the buffer on the
lhs was not big enough for a copy (or there wasn’t one), but simple
benchmarks with mktables show that even checking SvLEN(dstr) is enough
to slow things down, since the speed-up this provides is minimal where
short strings are involved.

Then I tried checking just the string length, and saw a consistent
speed increase.  So that’s what this patch uses.  Programs using short
strings will not benefit.  Programs using long strings may see a 1.5%
increase in speed, due to fewer string copies.
sv.c: String copy comments

This layout, which goes back to 765f542df2 in 2002, I find a bit con-
fusing.  The comments help.  (Though rewriting it might be better.)
 Granted, back in 2002 there wasn’t nearly as much code in any of
the branches.
Increase $constant::VERSION to 1.30
Peek.t: Update skip version

I did not have this branch ready in time for 5.19.6.
[Merge] Swiping PADTMPs’ string buffers

This branch allows PADTMPs’ string buffers to be stolen, benefiting
programs that use long strings by avoiding a few copies.