Previously, each `Matcher` had its own copy of a "blueprint"
`RegExp`, to isolate its `lastIndex` state.

We now explicitly store that state as a separate `position` field
in `Matcher`, which we assign to `lastIndex` before `exec`, and
read from `lastIndex` after `exec`.

This allows to reuse the same `RegExp` for all matchers of a given
`Pattern`, and to confine its use to `Pattern.execFind()`.

Previously, the constructor of `Matcher` accepted region params,
but the only call site always used the full string. This commit
confines the use of `subSequence` to the `region()` method.

Since we have to convert the input `CharSequence`s to `String`s
anyway to be able to give them to `js.RegExp`, it is better to do
that upon entry into our implementation. We can force the
`toString()`s to be at the call site, which can then be inlined and
removed when the arguments are already Strings, which should be the
vast majority of use cases.

And `undefined` for unmatched groups. In addition, store the start
and end of the whole match at index 0.

The indices array is cached directly as a field `indices` on the
`MatchResult`. This allows the cache to be better shared between a
`Matcher` and a `MatchResult`.

This corresponds to the format of the `indices` field of the
`regexp-match-indices` ECMAScript proposal, scheduled for inclusion
in ECMAScript 2022.

That feature is enabled by a flag, and not by default, because of
performance concerns. JS engine implementers have shown that
enabling the feature has a significant performance impact.
Therefore, we only enable it the first time group indices are
required for any given `Pattern` instance. This means that the
first match for which group indices are required will be run twice,
but this is probably the better trade-off.