Perl_re_op_compile(): add S_pat_upgrade_to_utf8()

Extract out the code that upgrades the pattern string to utf8 (and adjusts
any code-block indices) into a separate function, S_pat_upgrade_to_utf8().

As well as being tidier, we'll be calling the code from other places
shortly.
Perl_re_op_compile(): eliminate xend var

it's value is easily (re)calculated, and we no longer have to worry
about making sure we update it everywhere.
Perl_re_op_compile: eliminate clunky if (0) {}

There was a bit of code that did

    if (0) {
      redo_first_pass:
        ...foo...;
    }

to allow us to jump back and repeat the first pass, doing some extra stuff
the second time round. Since foo has now been abstracted into a separate
function, we can instead call it each time directly before jumping,
allowing us to remove the ugly if (0).
Perl_re_op_compile(): handle utf8 concating better

When concatting the list of arguments together to form a final pattern
string, the code formerly did a quick scan of all the args first, and
if any of them were SvUTF8, it set the (empty) destination string to UTF8
before concatting all the individual args. This avoided the pattern
getting upgraded to utf8 halfway through, and thus the indices for code
blocks becoming invalid.

However this was not 100% reliable because, as an "XXX" code comment of
mine pointed out, when overloading is involved it is possible for an arg
to appear initially not to be utf8, but to be utf8 when its value is
finally accessed. This results an obscure bug (as shown in the test added
for this commit), where literal /(?{code})/ still required 'use re
"eval"'.

The fix for this is to instead adjust the code block indices on the fly
if the pattern string happens to get upgraded to utf8. This is easy(er)
now that we have the new S_pat_upgrade_to_utf8() function.

As well as fixing the bug, this also simplifies the main concat loop in
the code, which will make it easier to handle interpolating arrays (e.g.
/@foo/) when we move the interpolation from the join op into the regex
engine itself shortly.
Perl_re_op_compile(): extract conatting code

Extract out the big chunk of code that concatenates the components
of a pattern string, into the new static function S_concat_pat().

As well as being tidier, it will shortly allow us to recursively
concatenate, and allow us to directly interpolate arrays such as
/@foo/, rather than relying on pp_join to do it for us.
combine regex concat overload loops

Currently when the components of a runtime regex (e.g. the "a", $x, "-"
in /a$x-/) are concatenated into a single pattern string, the handling of
magic and various types of overloading is done within two separate loops:
(in perlish pseudocode):

    foreach (@arg) {
        SvGETMAGIC($_);
        apply 'qr' overloading to $_;
    }
    foreach (@arg) {
        $pat .= $_, allowing for '.' and '""' overloading;
    }

This commit changes it to:

    foreach (@arg) {
        SvGETMAGIC($_);
        apply 'qr' overloading to $_;
        $pat .= $_, allowing for '.' and '""' overloading;
    }

Note that this is in theory a user-visible change in behaviour, since
the order in which various perl-level tie and overload functions get
called may change. But that was just a quirk of the current
implementation, rather than a documented feature.
re_op_compile: eliminate a local var and scope

Eliminate a local var and the block scope it is declared in
(There should be no functional changes).

Re-indenting will be in the next commit.
Perl_re_op_compile() re-indent code

Re-indent code after the previous commit removed a block scope.
Only whitespace changes.
S_pat_upgrade_to_utf8(): add num_code_blocks arg

This function was added a few commits ago in this branch. It's intended
to upgrade a pattern string to utf8, while simultaneously adjusting the
start/end byte indices of any code blocks. In two of the three places
it is called from, all code blocks will already have been processed,
so the number of code blocks equals pRExC_state->num_code_blocks.
In the third place however (S_concat_pat), not all code blocks have yet
been processed, so using num_code_blocks causes us to fall off the end of
the index array.

Add an extra arg to S_pat_upgrade_to_utf8() to tell it how many code
blocks exist so far.
Handle /@a/ array expansion within regex engine

Previously /a@{b}c/ would be parsed as

    regcomp('a', join($", @b), 'c')

This means that the array was flattened and its contents stringified before
hitting the regex engine.

Change it so that it is parsed as

    regcomp('a', @b, 'c')

(but where the array isn't flattened, but rather just the AV itself is
pushed onto the stack, c.f. push @b, ....).

This means that the regex engine itself can process any qr// objects
within the array, and correctly extract out any previously-compiled
code blocks (thus preserving the correct closure behaviour). This is
an improvement on 5.16.x behaviour, and brings it into line with the
newish 5.17.x behaviour for *scalar* vars where they happen to hold
regex objects.

It also fixes a regression from 5.16.x, which meant that you suddenly
needed a 'use re eval' in scope if any of the elements of the array were
a qr// object with code blocks (RT #115004).

It also means that 'qr' overloading is now handled within interpolated
arrays as well as scalars:

    use overload 'qr' => sub { return  qr/a/ };
    my $o = bless [];
    my @a = ($o);
    "a" =~ /^$o$/; # always worked
    "a" =~ /^@a$/; # now works too
[MERGE] Handle /@a/ array expansion within regex engine

This series of commits reorganises the code that concatenates and processes
the list of args in a run-time regular expression (fixing some bugs along
the way); then, most significantly, defers flattening and concatting an
array in /...@a.../ until the regex engine: so the engine gets to process
the individual elements of @a rather than being presented with a just a
final concatenated string. This allows us to improve the handling of code
blocks and overloading of the individual array elements.

Fixes RT #115004.