Offer checks as Roslyn analyzers for live in-IDE feedback

[Karzone]

Summary

Offer SpecHygiene's checks as Roslyn analyzers so authors get live feedback (squiggles + Error List entries) directly in Visual Studio / any IDE with the C# language service, in addition to the current CLI/report run.

Suggested by @304NotModified.

Why

Today feedback arrives only when someone runs the tool and opens the HTML report — out of band from the edit loop. Roslyn diagnostics would surface issues as the author types the .feature file, which is where they can act on them cheapest.

Feasibility

• A Roslyn DiagnosticAnalyzer can register for AdditionalFiles and analyze non-C# inputs, so it can lint .feature files directly (the files are wired in as AdditionalFiles / AdditionalText). This is the standard path for file-based analyzers.
• Ships as a NuGet analyzer package; diagnostics appear in-editor and in build output with zero extra author setup.

Scope / trade-offs

• Good fit for per-file checks: undefined placeholders, Scenario-with-Examples type errors, redundant steps, narrative/structure guards — these only need the single file and map cleanly onto per-file diagnostics.
• Poor fit for whole-suite checks: cross-scenario duplicate detection needs the entire spec set, which the per-file analyzer model doesn't provide. Keep those in the CLI report; the analyzer is a complement, not a replacement.
• New deliverable surface: separate analyzer project, AdditionalFiles wiring, diagnostic IDs/severities, NuGet packaging, and (optionally) code fixes.
• The i18n limitation (Only analyzes English feature files (# language: / localized keywords ignored) #1) applies here too — analyzers should reuse whatever dialect handling that issue lands.

Suggested first cut

Start with one high-value, unambiguous per-file rule (e.g. undefined placeholder / Scenario with Examples) as a proof-of-concept analyzer + NuGet package, then expand rule coverage.

Open questions

• Which rules give the most value inline vs. staying report-only?
• Include code fixes (e.g. Scenario: → Scenario Outline:), or diagnostics only for v1?
• Share the parsing/keyword logic with the CLI to avoid two divergent parsers.