parser: support Python-style implicit string concatenation

[rnvibes]

Problem

The chat template of gemma-4-E2B_q4_0-it.gguf (and other Gemini/Gemma-family
GGUFs) embeds a multi-line tool-call error message using Python-style adjacent
string concatenation:

{{- raise_exception(
    "chat_template: tool_calls[].function.arguments must be a "
    "JSON object (mapping), not a string. Deserialize arguments "
    "before passing to the template."
) -}}

Jinja (the reference implementation) accepts this — adjacent string literals
concatenate at the token level. Minja's parser rejects it with
Expected closing parenthesis in call args, so the model fails to load at all.

Change

In parseConstant(), after parsing a string literal, fold any immediately
following string literals (skipping whitespace) into the same Value. This
matches Jinja's semantics:

• "a" "b" → "ab"
• Only literal-to-literal folding — no behavior change for identifiers,
  operators (+, ~, |), or single literals.

Why this placement

Implicit concatenation is a token-level feature of the language (only string
literals fold), so parseConstant() is the correct single place — it is shared
by every expression context: call args, arrays, set statements, {{ }} output.

Verification

• A template containing the multi-line raise_exception(...) form now parses
  and renders.
• Existing expression forms ("a" + "b", "a" ~ "b", "a"|filter,
  identifiers) are unaffected — the fold only triggers when the next token is
  a string literal.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.