Fix lazy repetition endpoint matching across LOOP implementations

[drmeister]

Track the cursor explicitly in bounded and unbounded non-greedy constant-length matchers instead of relying on an arithmetic LOOP variable's value in FINALLY.

Clasp's LOOP uses Khazern, a portable LOOP implementation written by Robert Strandh and Tarn Burton, originally developed as part of SICL. See Robert Strandh, "A modern implementation of the LOOP macro," European Lisp Symposium, 2016:
https://metamodular.com/SICL/loop.pdf

The Khazern version in which this problem was observed leaves the arithmetic iteration variable at the last in-range position, causing the endpoint check to fail for patterns such as "^.+?$". Explicit advancement preserves the intended matching behavior without depending on this disputed LOOP interpretation.

I found the source code responsible for the problem with ChatGPT Astra.

Clasp returned the wrong result for:
(cl-ppcre:scan-to-strings "^.+?$" "Foo") --> NIL
It should return "Foo"

[stassats]

The new code is so ugly though.

[yitzchak]

Just for reference, I believe that Robert used the last paragraph in 6.1.2.1.1 as justification for this behavior. Specifically the sentence in italics:

In an iteration control clause, the for or as construct causes termination when the supplied limit is reached. That is, iteration continues until the value var is stepped to the exclusive or inclusive limit supplied by form2. The range is exclusive if form3 increases or decreases var to the value of form2 without reaching that value; the loop keywords below and above provide exclusive limits. An inclusive limit allows var to attain the value of form2; to, downto, and upto provide inclusive limits.

I think the existing loop might call next-fn excessively. I can play around with it a bit to see if I can come up with a "pretty" version.