Fixes #4894.

Summary

A text block whose content ends in an escaped backslash (\\) immediately before
the closing """ failed to parse, e.g.:

String s = """
    arbitrary text
    \\""";

produced Lexical error ... Encountered: <EOF> after : "". javac accepts this
form per JLS §3.10.6.

Root cause

In javaparser-core/src/main/javacc/java.jj, the TEXT_BLOCK_CONTENT rule only
treated \" as an atomic escape:

<IN_TEXT_BLOCK> MORE : { <TEXT_BLOCK_CONTENT: ( "\\" "\"" | ~[] ) > }

Given input \\""", JavaCC's longest-match consumed the first \ as a 1-char
~[] match, then matched the second \ together with the first " of the
closing delimiter as a 2-char \" escape — leaving only "", which can never
satisfy the 3-quote TEXT_BLOCK_LITERAL token. The lexer ran off the end of
input.

Fix

Recognise any \X (backslash + any character) as a single atomic chunk:

<IN_TEXT_BLOCK> MORE : { <TEXT_BLOCK_CONTENT: ( "\\" ~[] | ~[] ) > }

So \\ is now consumed as one unit and the closing """ stays intact. \"
continues to work (still a 2-char match, still wins over the 1-char fallback),
and bare " inside the block is unaffected because the 3-char
TEXT_BLOCK_LITERAL token outranks ~[] at the closer.

Tests

Two regression tests added in
javaparser-core-testing/.../ast/expr/TextBlockLiteralExprTest.java:

• textBlockEndingInDoubleBackslashAdjacentToCloserParses — canonical failing
  form from the issue (\\ immediately before """).
• textBlockEndingInDoubleBackslashOnSeparateLineParses — the \\ on its own
  line variant, asserting both raw value and translateEscapes() output.