Fix PARSE regression: THRU not matching at the end

Commit 44012cc1e7313f2fd3772e543f2f8b9096d90f9c introduced a regression
that causes THRU rules to fail when it matches to the end of input. A
simple test case illustrating the regression:

    >> parse "abcd" [thru "d"]
    == false  ;; Expected: true

Internally, this is caused by a left-over check that was previously used
to handle not-found results from the internal Find_* helpers. This check
tests against past-or-on (>=) end position, which is now wrong, because THRU
positioning happens before the check occurs and it is perfectly valid
for THRU to advance _to_ end position. So if anything, we'd have to
relax that check to test against past (>) end position. But even that is
not needed, because this check is no longer necessary at all, as all
matching branches correctly check on their own for NOT_FOUND results.

There is one occurrence of the "old" pattern for testing against
NOT_FOUND left in the Parse_To function. This will be corrected for
consistency in a follow-up commit.

The regression was originally reported by Boleslav Brezovsky on AltME.

This fixes CureCode issue #1959.
Improve consistency of NOT_FOUND/THRU handling in Parse_To

Use the "new" style of handling NOT_FOUND in combination with THRU
positioning also for the block! parsing case. This relies on the fact
that Find_Block does (a) not position past tail when it matches, (b)
returns NOT_FOUND when it fails to match.

The old check (`i >= series->tail`) worked because of signed/unsigned
integer arithmetics: `i` is unsigned, `NOT_FOUND` is defined as `-1`, so
`i = NOT_FOUND` wraps around to an `i` that is `>= series->tail`. So in
combination with the fact that Find_Block doesn't position past the end,
the old check is effectively equal to `i == NOT_FOUND`. This is made
explicit by the new implementation.

The same handling of NOT_FOUND/THRU is already used in the other cases
of Parse_To (string+string, string+char).