Fix Windows backslash path separators in JSON output and diagnostics

[cderv]

On Windows, pampa's JSON writer and ariadne diagnostics show backslash-separated file paths, diverging from the forward-slash convention used everywhere else in the codebase (quarto_util::to_forward_slashes, already used for Lua/HTML/DocumentProfile paths) and from insta snapshots recorded on Unix. TypeScript Quarto normalizes the same way via pathWithForwardSlashes for the same reason.

Root Cause

ASTContext::with_filename stores whatever filename string it's handed verbatim. On Windows, callers that derive the filename from a real path (glob() results in the snapshot-test harness, CLI arguments) produce backslash-separated strings, which the JSON writer and SourceContext-based diagnostics then read back out unchanged.

Fix

Normalizes at the ASTContext ingress points (with_filename, add_filename), which covers the JSON writer and diagnostics built from SourceContext for free. Two more un-normalized ingress points surfaced during end-to-end verification and review, and got the same treatment:

• main.rs's ad hoc fallback SourceContext on the hard-parse-error CLI path, built directly from the raw CLI argument, bypassing ASTContext entirely.
• The qmd and commonmark readers each re-add the filename into context.source_context right after with_filename had already normalized it — for qmd this fully replaced the normalized entry, so warnings on an otherwise-successful parse still showed backslashes.

Left main.rs's "Missing Newline at End of File" CLI warning alone — it interpolates the raw CLI argument into a plain sentence, echoing the user's own typed path back to them rather than emitting a portable identifier, which matches how rustc/cat handle this.

Test Plan

• Confirm astContext.files[].name in JSON output uses forward slashes for a backslash-separated input path
• Confirm ariadne diagnostics (both the hard-parse-error path and warnings on a successful parse) show forward-slash paths on Windows
• Confirm the full pampa crate test suite passes (aside from the pre-existing, unrelated CRLF byte-offset failures)

[cderv]

@cscheid asking for review to check this is the right approach: Normalize to '/' all the paths.

It think this is the right call to make our life easier.

[cscheid]

Looks good to me, excellent. I'm slightly terrified of the following question but I will ask it anyway, ha: are forward slashes valid characters in windows file names? I love the idea of normalizing everything to / at the deepest level of filename resolution, but I'm genuinely unsure what the actual rules for filenames on windows are.

[cderv]

Good question! Here is what I remember from last time I checked this:

/ is actually one of the reserved characters Windows forbids inside an individual file directory name component — my go-to page is Naming Files, Paths, and Namespaces. So it can never collide with a legitimate filename.

As a path separator though, / is accepted interchangeably with \ by ordinary Windows path parsing — this is true at the Win32 level, and in PowerShell (which explicitly documents allowing either for cross-platform compat). I checked also in Rust and std::path works that way.
So normalizing our output to / is safe — nothing we emit could ever get misinterpreted if fed back into a real Windows path API.

However, and this is the big BUT: under the \\?\ verbatim prefix, used sometimes for long absolute paths, / stops being treated as a separator and becomes a literal character instead. I think that prefix is only relevant to raw OS-API calls though, not to what this PR touches, so we're not at risk here.

Also, remote paths on network drives (UNC paths) also accept // in place of \\ — same interchangeability rule applies there too.