Publish only the match a backward search answers with - #7149

The engine searches forward only, so `String#rindex`, `String#byterindex`
and `String#rpartition` reach their answer by walking the subject from the
start through `__regexp_rsearch`, keeping the last match that starts at or
before the limit. The walk spoke characters, and a character offset is not a
place a subject can be read from: `Regexp.__search` counts one out from the
start of the subject to reach the byte offset the engine takes, and
`MatchData#begin` counts a byte offset back the same way. Every turn asked
for both, and `rindex` and `rpartition` asked for the second twice, so a
walk over a multibyte subject read the whole of it three times per match and
took quadratic time. On a full-core build `("あb" * 5000).rindex(/b/)` took
0.174s, doubling the subject took 0.584s, and doubling it again took 2.315s,
against 0.012s for the ASCII twin of the middle one, whose offsets are its
bytes and need no counting at all.

Walk in bytes. Nothing is given up by leaving character space: a byte inside
a character is not a position a match can start at, and the engine steps
over one rather than seed an attempt there, in `nfa_exec()`, `bt_exec()` and
`literal_exec()` alike, so resuming at `md.__byte_begin(0) + 1` reaches the
next character by itself. Resuming one position past the match start rather
than at the match end is what keeps an overlapping match in view, and one
byte past keeps it the same way one character past did. The three now take
0.007s, 0.019s and 0.060s, and the ASCII subject is where it was.

`limit` is a byte offset for every caller, which is what `byterindex`
already handed it. `rindex` reads the character position it was given into
one where it is given, once, and the whole subject is its own byte length
rather than a reading of it, which is the form `rindex` is in whenever it is
called with one argument. `Regexp.__byte_search` does not range check its
position, so the walk stops itself at the end of the subject.

What remains is the subject each search publishes: a match sets the pre and
post match globals, which copies the subject once per match. That is common
to every search loop in the gem and is left where it is.

A match publishes thirteen names, and the tests that ask what `rindex`,
`byterindex` and `rpartition` leave behind read back two of them, `$~` and
`$1`. The other eleven are published by the same act and go unasked, which
is the whole of what a walk that passes matches on the way to its answer has
to get right: the one it settled on is the one that must be standing, and a
walk that found nothing must leave nothing standing at all.

Ask for the match, the two pieces the subject is cut into, a second group, a
group that did not take part, the last one that did, and the same set after
a search that missed. The answers are the ones CRuby gives.

A search publishes its match on the way out: `$~`, the nine numbered groups,
the match itself, the two pieces the subject is cut into around it, and the
last group that took part. Cutting the subject in two copies the whole of it,
so a search costs its subject once over whether or not anything reads what it
published.

`String#rindex`, `String#byterindex` and `String#rpartition` walk the subject
and keep the last match that qualifies, and every match the walk passes is
published and then replaced by the next one. The walk already publishes its
answer itself at the end, with `MatchData#__set_globals`, so what the searches
published was read by nothing. It was still paid for: the subject copied once
per match, which is quadratic in the subject and is what the walk costs once
the character counting is out of it.

Let a search be told to publish nothing. `Regexp.__byte_search` takes it as an
argument, the way CRuby's `rb_reg_search0()` takes `set_backref_str`, and a
search that publishes nothing clears nothing either, so the globals come out
of it as they went in and the caller owns them throughout. The walk passes
FALSE and keeps the two lines that publish its answer or clear for a miss.
`gsub`, `scan` and the rest cannot be told the same thing, since the block
they call reads the globals of the match it was handed.

`("あb" * 20000).rindex(/b/)` goes from 0.060s to 0.007s, and doubling the
subject now doubles the time rather than tripling it. The single-byte subject
was paying the same copy and had nothing to do with characters: `("ab" *
20000).rindex(/b/)` goes from 0.034s to 0.007s.