Fix GB12/GB13 when the regional indicator count is already known

[cometkim]

A GraphemeCursor driven forward in chunks splits a flag in two:

let s = "a\u{1F1E6}\u{1F1E6}"; // 'a' followed by two regional indicators

// s.graphemes(true)                    -> ["a", "🇦🇦"] boundaries [1, 9]
// GraphemeCursor over the whole string -> boundaries [1, 9]
// GraphemeCursor fed in chunks         -> boundaries [1, 5, 9] <-- wrong

Reproduces on 1.13.3. Both extended and legacy mode, and every chunk size.

ris_count has two readers with incompatible expectations. next_boundary maintains it as "the number of RIS immediately preceding offset", which is what the field's doc comment says. handle_regional instead treats it as an accumulator for the backward walk it is about to perform. It seeds ris_count from the field and then increments it for each RIS it walks over.

That is correct when handle_regional is resuming a walk it started itself across an earlier chunk. It is wrong when the field was populated by forward iteration, because the codepoints it walks back over are the very ones already counted, so they are counted twice and an odd run reads as even.

Failing test first, then the fix commit follows.

[cometkim]

I just noticed that the same issue was reported already in #174. This PR should fix it.

[Manishearth]

Clippy failure unrelated