Add more tests of lexer's skipToLeadingKeyword behavior

[Rangi42]

These three tests are related to how "skipping" and "capturing" work. ("Skipping" occurs when an untaken if/elif/else needs to skip to the next elif/else/endc, or when a break inside a rept/for skips to its endr. "Capturing" occurs when a rept/for or a macro body stores its contents up to its endr/endm.)

Skipping and capturing both use the skipToLeadingKeyword function to skip lines until finding one that starts with an appropriate "ending" keyword (endc/endr/endm/etc). Expansions are disabled during this process, so you can't do e.g. def s equs "endr" and then {s} to end a loop.

"Blue-painting", however, does occur while skipping and capturing (naturally -- it's a low-level behavior of peek() and skipChar(), which are used by skipToLeadingKeyword just like everywhere else in the lexer that advances through the assembly code). So to detect the ending keyword, the character after the ending keyword has already been peeked and thus painted blue -- and this happens while expansions are disabled, so even if that character is a { brace it won't start an interpolation, nor will \ start a macro argument.

Currently the Rust rewrite does not blue-paint during its equivalent of skipping/capturing, so it handles these tests differently (see https://codeberg.org/ISSOtm/rsgbds/issues/53). This is considered a bug, but we may want to further change/refine its behavior in ways inconsistent with how C++ RGBASM currently behaves.

These tests are also intended to allow more confidently optimizing skipToLeadingKeyword, since it's a fairly significant part of the overall runtime on real-world projects (see #1968).

[ISSOtm]

Behaviour looks fine, thanks :)