Revert "Define RXf_SPLIT and RXf_SKIPWHITE as 0"

This effectively reverts commit cccd1425414e6518c1fc8b7bcaccfb119320c513.

We dont want to get rid of these vars, and it turns out that
RXf_SEEN_LOOKBEHIND is used only in the same situation of the new
RXf_MODIFIES_VARS. So I have renamed RXf_SEEN_LOOKBEHIND to
RXf_NO_INPLACE_SUBST, and then instead of using two vars we use
only the one. Which in turn allows RXf_SPLIT and RXf_SKIPWHITE to
have their bits back.

This is in preparation for reverting another patch in this sequence.
Revert "[perl #94490] const fold should not trigger special split " ""

Revert, with minor changes and some merges: 5255171e6cd0accee6f76ea2980e32b3b5b8e171

The reverted patch was meant to make:

        split( 0 || " ", $thing )            #1

consistent with

        my $x=0; split( $x || " ", $thing )  #2

and not with

        split( " ", $thing )                 #3

This was reverted because it broke C<split("\x{20}", $thing)>, and
because one might argue that is not that #1 does the wrong thing,
but rather that the behavior of #2 that is wrong. In other words
we might expect that all three should behave the same as #3, and
that instead of "fixing" the behavior of #1 to be like #2, we should
really fix the behavior of #2 to behave like #3.

Also, it doesn't make sense to move this further from the regex
engine. We really want the regex engine to decide this stuff itself,
otherwise split " ", ... wouldn't work properly with an alternate
engine. (Imagine we add a special regexp meta pattern that behaves
the same as " " does in a split /.../. For instance we might make
split /(*SPLITWHITE)/ trigger the same behavior as split " ".

Anyway, it can wait until after 5.18 to figure it out. The op logic
involved in this stuff makes my head spin.
make it so that run time patterns can trigger SKIPWHITE/WHITE

This probably neutralizes RT #94490.

Prior to this patch the special RXf_SKIPWHITE behavior of

    split(" ", $thing)

was only available if Perl could resolve the first argument to
split at compile time, meaning under various arcane situations.

This manifested as oddities like

    my $delim = $cond ? " " : qr/\s+/;
    split $delim, $string;

and

    split $cond ? " ", qr/\s+/, $string

not behaving the same as:

    ($cond ? split(" ", $string) : split(/\s+/, $string))

which isn't very convenient.

This patch changes this by adding a new flag to the op_pmflags,
PMf_SPLIT which enabled pp_regcomp() to know whether it was called
as part of split, which would allow the RXf_SPLIT to be passed into
the run time compilation. We could use optree inspection for this instead,
but a follow up patch will reoganize things so that the extra flags
works with stuff we already have to do.

Working on this revealed a secondary issue: when we check if we need to
recompile a pattern in pp_regcomp() we did not check the flags to see
if they are the same. So doing something like this:

    split $x ? " " : qr/ /, $string;

repeatedly would never exhibit the " " behavior once the qr/ / behavior
was exhibited, as the two patterns would have the same pattern and
length, despite having different flags. I added a flag test to the cache
logic, but I doubt it is sufficient: flags get turned on as we compile,
and even maybe turned off, so a simple comparison doesnt really work.
For now we ensure that expected extflags are all on in the cached
regex. I'm not sure what to do about this other than store the original
extflags in the regex (in addition to the actual extflags).

It is possible that this problem affects other cases where we have
flags that affect compilation that are not part of the compiled pattern.

Which makes me think what we really need is a magic pattern (*SKIPWHITE)
which acts like \s+ but triggers the SKIPWHITE behavior (split ' ') from
a regexp. If we pretended we compiled a (*SKIPWHITE) then we would be
able to tell the branches apart in split $x ? " " : qr/ / by comparing
the pattern alone. (Something like that).
simplify some of the logic related to the new PMf_SPLIT flags by reorganizing bits