fix: treat backslash as escape character only inside quoted strings, matching Jinja2 behaviour (fixes #1304)

[jmoraleda]

This PR implements the fix discussed in #1304 , and builds on the scanner infrastructure introduced in #1305 (configurable multi-character delimiters).

Background

In Python's Jinja2, the template scanner is not responsible for backslash interpretation. It locates delimiters, extracts the raw content between them, and passes it to the expression parser. Backslash handling inside string literals is the expression parser's concern. A bare backslash outside a string literal is invalid Python, so Jinja2 never needs to handle it at the scanner level.

Jinjava's TokenScanner has historically handled backslash unconditionally in both the char-based and string-based scanning paths:

if (c == '\\') {
    ++currPost; // skips the next character regardless of quote context
    continue;
}

This has two consequences:

1. Outside quoted strings: a \ followed by a closing delimiter (e.g. \}}) prevents the delimiter from being recognized. The block runs to the next valid closer, swallowing surrounding text. The resulting expression content is a JUEL lexical error.
2. Inside quoted strings: works by accident for simple cases, but the scanner pre-consumes the escaped character before JUEL sees it.

What this PR adds

A new LegacyOverrides flag handleBackslashInQuotesOnly. When true, backslash is treated as an escape character only inside quoted string literals — matching Jinja2 behaviour — and is left untouched outside quotes for the expression parser to handle. Both the char-based and string-based scanning paths respect this flag.

LegacyOverrides preset behaviour

• LegacyOverrides.NONE — flag is false (legacy behaviour, default).
• LegacyOverrides.THREE_POINT_0 — flag is false. Although this represents the "correct" behaviour, it is not included here because existing templates in production may rely on \}} preventing delimiter recognition, and THREE_POINT_0 is the current default config in Jinjava. Changing it would be a silent breaking change.
• LegacyOverrides.ALL — flag is true. ALL is explicitly documented as opting into all new correct behaviours, and the existing test suite passes with this setting.

If the maintainers wish to include this in THREE_POINT_0, the only required change is to update the existing test TokenScannerTest.itTreatsEscapedQuotesSameWhenNotInQuotes to build its config with handleBackslashInQuotesOnly explicitly set to false, isolating it from the preset value. That is a one-line change and we are happy to include it in this PR if desired.

Tests

BackslashHandlingTest covers all four combinations of char-based / string-based scanner × legacy / new flag:

• Escaped quotes inside string literals work correctly in both modes.
• The token boundary difference is verified directly via TokenScanner (rather than render(), which throws a FatalTemplateErrorsException in both modes because the expression x \ is a JUEL lexical error). In legacy mode, "prefix {{ x \}} suffix }}" produces two tokens — TEXT "prefix " and EXPR "{{ x \}} suffix }}". In new mode it produces three — TEXT "prefix ", EXPR "{{ x \}}", TEXT " suffix }}".
• Backslash in variable values (not the template itself) is unaffected by either mode.
• The LegacyOverrides preset values are explicitly asserted with comments documenting the rationale.