Implement JDK8 zero-width match semantics in String.split

[rootkiller6788]

Description

Fixes #143: j2cl's String.split did not implement JDK8 zero-width match semantics.

"abc".split("") returned {"", "a", "b", "c"} on JDK8+ runtimes where the JRE returns {"a", "b", "c"}. The root cause was that split re-ran the regex against progressively trimmed suffixes of the input, so any zero-width-capable regex (empty regex, \b, lookaheads, a*/b*/\s*, ^) re-matched at the start of each trimmed suffix and produced an extra empty leading piece.

Change

Rewrote String.split(String, int) to mirror java.util.regex.Pattern.split:

• matches are found on the whole input, advancing a split index;
• the global regex lastIndex is kept in sync so zero-width matches still make progress (mimicking Matcher);
• a zero-width match at the very beginning is skipped, so no empty leading substring is produced;
• the remaining piece after the last match is emitted according to the limit rules;
• the trailing-empty trimming for limit==0 is preserved.

Verification

• Ported the new algorithm character-for-character to JS and compared against a real JDK8 String.split oracle over 4200 (input, regex, limit) combinations: 4194/4200 match. The 6 remaining differences are all the Java $ regex matching before a final line terminator (Java regex engine semantic) which is outside the split algorithm and is already documented in the split javadoc as a JS-vs-Java regex difference.
• All existing StringTest split assertions pass, including the issue2742 "/".split("/", 0) edge case.
• testSplit_emptyExpr now asserts JDK8 semantics and covers the limit variants.

Type

Bug fix.