Stop pos() from being confused by changing utf8ness

The value of pos() is stored as a byte offset.  If it is stored on a
tied variable or a reference (or glob), then the stringification could
change, resulting in pos() now pointing to a different character off-
set or pointing to the middle of a character:

$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, a; print pos $x'
2
$ ./perl -Ilib -le '$x = bless [], chr 256; pos $x=1; bless $x, "\x{1000}"; print pos $x'
Malformed UTF-8 character (unexpected end of string) in match position at -e line 1.
0

So pos() should be stored as a character offset.

The regular expression engine expects byte offsets always, so allow it
to store bytes when possible (a pure non-magical string) but use char-
acters otherwise.

This does result in more complexity than I should like, but the alter-
native (always storing a character offset) would slow down regular
expressions, which is a big no-no.
Stop minlen regexp optimisation from rejecting long strings

This fixes #112790 and part of #116907.

The length of the string is cast to I32, so it wraps and end up less
than the minimum length.

For now, simply skip this optimisation if minlen itself wraps and
becomes negative.
pp_hot.c: Show lengths in -Dr output for minlen optimisation
[perl #116907] Allow //g matching past 2**31 threshold

Change the internal fields for storing positions so that //g in scalar
context can move past the 2**31 character threshold.  Before this com-
mit, the numbers would wrap, resulting in assertion failures.

The changes in this commit are only enough to get the added test pass-
ing.  Stay tuned for more.
Make $' work past the 2**31 threshold
Make @- and @+ return correct offsets beyond 2**31
Stop values from ‘sticking’ to @- and @+ elems

These arrays are very similar to tied arrays, in that the elements are
created on the fly when looked up.  So push @_, \$+[0], \$+[0], will
push references to two different scalars on to @_.

That they are created on the fly prevents this bug from showing up
in most code:  If you reference the element you can observe that, on
FETCH, it gets set to the corresponding offset *if* the last match has
a set of capturing parentheses with the right number.  Otherwise, the
value in the element is left as-is.

So, doing another pattern match with, say, 5 captures and then another
with fewer will leave $+[5] and $-[5] holding values from the first
match, if there is a FETCH in between the two matches:

$ perl -le '"  "=~/()()()()(..)/; $_ = \$+[5]; print $$_; ""=~ /()/; print $$_;'
2
2

And attempts at assignment will succeed, even though they croak:

$ perl -le 'for ($-[0]) { eval { $_ = *foo }; print $_ }'
*main::foo

The solution here is to make the magic ‘get’ handler set the SV
no matter what, instead of just setting it when it refers to a
valid offset.
Fix assertion failure with $#a=\1

If the array has been freed and a reference is then assigned to
the arylen scalar and then get-magic is called on that scalar,
Perl_magic_getarylen misbehaves.  SvOK_off is not sufficient if
arbitrary values can be assigned by Perl code.  Globs, refs and
regexps (among others) need special handling, which sv_setsv
knows how to do.
Fix assert fail when fetching pos clobbers ref with undef

pos($x) returns a special magical scalar that sets the match position
on $x.  Calling pos($x) twice will provide two such scalars.  If we
set one of them to a reference, set the other to undef, and then read
the first, all hail breaks loose, because of the use of SvOK_off.

SvOK_off is not sufficient if arbitrary values can be assigned by Perl
code.  Globs, refs and regexps (among others) need special handling,
which sv_setsv knows how to do.
Remove null check from mg.c:magic_getvec

lsv can never be null here.  This null check has been here since
vec’s get-magic was added in ae389c8a or 6ff81951f7.
regexec.c:regexec_flags: Remove unused var

This variable, end_shift, only ever holds the value 0.  It is used in
only one place, where its value is assigned to another variable.

The history is interesting:

start_shift and end_shift were added in c277df42229, which added sub-
string optimisations.  146174a91a192 rearranged stuff a bit, causing
these variables to be unused.  155aba94f6 commented out the unused
start_shift to suppress a compiler warning.  1df70142a966e remove=
the start_shift comment, leaving the comment describing end_shift
nonsensical.
Stop substr re optimisation from rejecting long strs

Using I32 for the fields that record information about the location of
a fixed string that must be found for a regular expression to match
can result in match failures, because I32 is not large enough to store
offsets >= 2**31.

SSize_t is appropriate, since it is 64 bits on 64-bit platforms and 32
bits on 32-bit platforms.

This commit changes enough instances of I32 to SSize_t to get the
added test passing and suppress compiler warnings.  A later commit
will change many more.
Use SSize_t/STRLEN in more places in regexp code

As part of getting the regexp engine to handle long strings, this com-
mit changes any variables, parameters and struct members that hold
lengths of the string being matched against (or parts thereof) to use
SSize_t or STRLEN instead of [IU]32.

To avoid having to change any logic, I kept the signedness the same.

I did not change anything that affects the length of the regular
expression itself, so regexps are still practically limited to
I32_MAX.  Changing that would involve changing the size of regnodes,
which would be a lot more involved.

These changes should fix bugs, but are very hard to test.  In most
cases, I don’t know the regexp engine well enough to come up with test
cases that test the paths in question with long strings.  In other
cases I don’t have a box with enough memory to test the fix.