[mvanhorn]

Why

A custom inline parser that has already read an opener often needs the last closer before the next whitespace or the end of the text. Reaching that closer from the current position means scanning forward and scanning again to confirm the match is the last one, which is awkward for the caller and does extra work.

What changed

• prev steps back one UTF-16 code unit, including across the synthetic newline between lines, and leaves the position unchanged at the start of the input.
• findPrev searches backward for a character or a CharMatcher, with overloads that take an inclusive lower position so the search can stop at a saved opener.
• The current character is included, and the end sentinel is skipped and never matches.
• A hit returns how many code units were moved. A miss returns -1 while staying at the start of the input or at the bound.
• A bound after the current position or outside the input throws IllegalArgumentException before the position changes.

Testing

./mvnw -B -ntp -pl commonmark -am test -Dtest=InlineContentParserTest,ScannerTest -Dsurefire.failIfNoSpecifiedTests=false passed locally (ScannerTest 11 tests, InlineContentParserTest 3 tests, no failures). The same command passed 14 tests in a Linux container (eclipse-temurin:21-jdk).

Fixes #395