fix: parse heredocs with a single-character delimiter (#314)

[kkozik-amplify]

caused by #314

Problem

<<E fails to parse while <<EO succeeds. The spec defines the delimiter as an Identifier:

heredocTemplate = (("<<" | "<<-") Identifier Newline ... Identifier Newline);
Identifier      = ID_Start (ID_Continue | '-')*;

The trailing * permits a single character. The grammar used +, requiring a second one, so <<E fell through to STRING_CHARS.

Long-standing rather than a v8 regression — the same pattern is present pre-8.x.

The fix is in two places, not one

Relaxing + → * in hcl2.lark makes <<E parse, and the full suite stayed green. That was misleading: hcl2/utils.py carries a duplicate of the delimiter regex in HEREDOC_PATTERN / HEREDOC_TRIM_PATTERN, which re-match a token the grammar has already accepted. With only the grammar relaxed:

hcl2.loads("a = <<E\nx\nE\n", serialization_options=SerializationOptions(preserve_heredocs=False))
# RuntimeError: Invalid Heredoc token: <<E\nx\nE

The grammar accepted it and the serializer then rejected it. Nothing in the existing suite flattens a single-character heredoc, so this only surfaced because the new tests cover the flatten path. Both sites now carry a comment noting they must track each other — this is the third time they have drifted (see also the CRLF work in #317).

Tests

TestSingleCharacterHeredocDelimiter — plain and trimmed forms, empty body, flattening, an attribute after the heredoc, and a body line ending in the delimiter (sayE / E), which matters more at one character since an accidental match is likelier. A multi-character control confirms nothing shifted.

Without the grammar change, 6 of the 7 fail.

Test plan

• Full suite: 1511 passing (baseline 1504)
• pre-commit run: clean
• No lexing ambiguity observed; STRING_CHARS and the operator terminals are unaffected

Scope: the character class is deliberately untouched

This PR changes the delimiter's length rule (+ → *), not its character class. Worth being explicit, because the spec argument above would also implicate the class, and it does not line up with the grammar's own identifier terminal in either direction:

Delimiter	Heredoc	Valid identifier (NAME)
_EOF	rejected	accepted
EO.F	accepted	rejected
EO_F, EO-F, E1	accepted	accepted
1E	rejected	rejected

NAME is [a-zA-Z_][a-zA-Z0-9_-]*; the heredoc delimiter is [a-zA-Z][a-zA-Z0-9._-]*. So a leading underscore is a valid identifier but not a valid delimiter, and a dot is a valid delimiter but not a valid identifier.

Left alone on purpose: #314 is specifically about length, nobody has reported the class, and changing it would widen what the lexer accepts on a path that has already needed three corrections this cycle. Filing it separately if we want it.

Test scope

Unit tests only, no integration fixture — the same call made for the empty-heredoc fix in #312. The behaviour is a lexer-level accept/reject plus one flatten path, both of which unit tests cover directly; a golden fixture would add four files without adding signal.