Add structured render warnings and diagnostics

[osteele]

Summary

Add a backward-compatible API for reporting non-fatal diagnostics alongside rendered output. Callers should be able to surface portability problems or suspicious template constructs without failing a render.

Current status

The original dot-assignment motivation no longer describes the implementation. With Jekyll extensions enabled, {% assign page.canonical_url = value %} is parsed as a path assignment and updates a nested map through SetPath; it is not stored under an inaccessible literal key. With Jekyll extensions disabled, the syntax remains a parse error.

The diagnostics API is still useful, but dot assignment should not be changed into a warning or no-op as part of this issue.

Proposed direction

Add a detailed render method that returns output plus structured diagnostics, while leaving existing render methods unchanged. For example:

type RenderResult struct {
    Output   []byte
    Warnings []Warning
}

type Warning struct {
    Loc     parser.SourceLoc
    Code    string
    Message string
}

The exact names are open to design review.

Requirements

• Existing parse and render APIs keep their current behavior.
• Diagnostics belong to one render operation, not shared mutable engine configuration.
• Concurrent renders remain safe and cannot mix diagnostics.
• Locations identify the originating template, including included or rendered files.
• Callers can choose whether warnings are informational or promoted to errors.
• Tests cover multiple warnings, nested templates, and concurrent renders.

Candidate uses

• Compatibility behavior that is accepted but differs from Shopify Liquid.
• Deprecated syntax or features.
• Recoverable template-store or rendering fallbacks.
• Suspicious constructs that are valid but likely unintended.

Related

• Feature request: object attribute assign gojekyll#60
• feat: enable Jekyll-compatible dot notation in assign tags gojekyll#120