make qr/(?{})/ behave with closures

With this commit, qr// with a literal (compile-time) code block
will Do the Right Thing as regards closures and the scope of lexical vars;
in particular, the following now creates three regexes that match 1, 2
and 3:

    for my $i (0..2) {
        push @r, qr/^(??{$i})$/;
    }
    "1" =~ $r[1]; # matches

Previously, $i would be evaluated as undef in all 3 patterns.

This is achieved by wrapping the compilation of the pattern within a
new anonymous CV, which is then attached to the pattern. At run-time
pp_qr() clones the CV as well as copying the REGEXP; and when the code
block is executed, it does so using the pad of the cloned CV.
Which makes everything come out all right in the wash.

The CV is stored in a new field of the REGEXP, called qr_anoncv.

Note that run-time qr//s are still not fixed, e.g. qr/$foo(?{...})/;
nor is it yet fixed where the qr// is embedded within another pattern:
continuing with the code example from above,

    my $i = 99;
    "1"   =~ $r[1];    # bare qr:     matches: correct!
    "X99" =~ /X$r[1]/; # embedded qr: matches: whoops, it's still
					       seeing the wrong $i

0 files changed, 0 insertions, 0 deletions