Support --learn for inline expectation tests - #22228

The `--learn` support that follows needs to render inline-expectation
comments in the syntax of the file being edited, and a single CodeQL
database can mix source languages (e.g. Java plus XML), so the marker
must be chosen per file rather than per database.

Extend `TestPostProcessing::InputSig` with `getStartCommentMarker(relativePath)`
(no result -> that file is left untouched by `--learn`) and a defaulted
`getEndCommentMarker(relativePath)` (`none()` by default: line-comment
languages render no closing marker; block-comment languages can override
it later). Each language's `InlineExpectationsTestQuery.ql` implements
`getStartCommentMarker`, gated to that language's own source extensions so
that other file types (XML/YAML/HTML/ERB/Razor) extracted into the same
database are not rewritten with the wrong syntax.

This commit only wires the marker API through the signature and the
per-language inputs; nothing consumes it yet, so behavior is unchanged.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1adfa307-c48e-43f5-94e3-8286e4a8c083

`codeql test run --learn` could previously only rewrite `.expected`
files; inline expectations (the `// $ Alert` comments checked by
`InlineExpectationsTest`) had to be fixed by hand. This teaches the
shared test library to compute those source edits so the test runner
can apply them.

The `test-postprocess` query now exposes a `learnEdits` relation
(`file, line, operation, startColumn, endColumn, text`) describing the
minimal source rewrite that would make the inline expectations match the
actual query results. It covers:

  - appending a fresh comment carrying every tag learned for a line that
    has an unexpected result and no existing comment to merge into;
  - rewriting an existing expectation comment as a whole so it matches
    the current results: dropping fixed-spurious tags, promoting a
    `MISSING:` expectation that now fires, clearing a stale `SPURIOUS:`
    annotation, and merging in freshly learned tags, re-rendering the
    remaining expectations (or deleting the comment when none remain);
  - preserving expectations this test does not own -- e.g. a tag
    annotated with a different query's id that shares the source file --
    and any trailing regular note (`// $ Alert // note`);
  - recording any unexpected result, not just `Alert`.

The comment syntax comes from the `getStartCommentMarker` /
`getEndCommentMarker` markers added to `InputSig` in the previous commit,
so `LearnEditsImpl` renders each edit in the target file's own syntax and
stays language-agnostic. Edits are emitted as a query predicate rather
than applied here: the engine consumes `learnEdits` only under `--learn`
and ignores it otherwise, so ordinary `test run` output is unchanged. The
supporting predicates are wrapped in a `private module LearnEditsImpl` so
only the `query predicate learnEdits` is re-exposed.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1adfa307-c48e-43f5-94e3-8286e4a8c083

`getAnExpectation` is a relation that holds between an expectation comment
and the parsed parts it carries, not a function returning a single value,
so the `get` prefix is misleading and trips the CodeQL predicate-naming
style check. Rename it to `hasExpectation`, matching the `has`-prefixed
convention for such predicates (and the sibling `hasExpectationWithValue`).

Pure rename with no behavior change; reformatted with `codeql query format`.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1adfa307-c48e-43f5-94e3-8286e4a8c083