Let users opt in to analyzing generated code

[meziantou]

What

Adds an opt-in so users can have the rules analyze and report on generated code:

MEZIANTOU_ANALYZER_GENERATED_CODE=true

Unset (the default), nothing changes.

Why

Most analyzers pass GeneratedCodeAnalysisFlags.None, which is the right default for the vast majority of projects, but some users do want the rules applied to generated code and had no way to ask for it.

An .editorconfig option cannot express this: ConfigureGeneratedCodeAnalysis must be called from Initialize(AnalysisContext), and AnalyzerOptions is only reachable from the analysis callbacks, which run later. An environment variable is the only configuration that can be read early enough.

How

The value is OR-ed with the flags of each analyzer, so it can only add analysis, never remove it. The 13 rules that already pass Analyze | ReportDiagnostics — the Blazor and source-generator ones, where the generated file is the subject — are unaffected and cannot be disabled with it. There is deliberately no opt-out and no per-rule override (ConfigureGeneratedCodeAnalysis is per-analyzer, not per-diagnostic, and several analyzers expose many rule ids, so a per-rule switch would be misleading).

The 166 analyzers now call AnalysisContextExtensions.ConfigureAnalysisOfGeneratedCode instead of ConfigureGeneratedCodeAnalysis. The argument at each call site is unchanged — it became the minimum rather than the value.

Notes for the reviewer

Two things surfaced while implementing this:

• src/Meziantou.Analyzer/BannedSymbols.txt was inert. Meziantou.NET.Sdk only injects its own configuration/BannedSymbols.txt and does not glob project-local ones, so the existing GetTypeByMetadataName ban was never enforced. It is now added to AdditionalFiles, which is what makes the new ban on ConfigureGeneratedCodeAnalysis a compile error rather than a convention. There were zero pre-existing violations of the old ban.
• RS1025 is now in NoWarn for the analyzer project: it wants a direct call to ConfigureGeneratedCodeAnalysis in Initialize and cannot see through the extension method. The banned symbol covers the same ground more strictly. RS1035 (environment variables are banned in analyzers) needed a pragma in the new file — verified that it does fire without it.

Also closed an unterminated code fence at the end of README.md, which would otherwise have swallowed the new section.

Testing

• All five Roslyn versions build clean; the full suite passes: 18112 tests, 0 failed.
• New tests: 14 theory cases over the value parsing, plus 6 end-to-end cases. The end-to-end ones use a test-only wrapper analyzer (ProjectBuilder.WithGeneratedCodeAnalysis) that overrides the flags rather than setting the environment variable, because the tests run with ParallelMode.All and mutating the process state would race with the tests that compile real source-generator output.
• Checked manually against the packed NuGet package: MA0017 is reported in a .g.cs file only when the variable is set.
• dotnet run --project src/DocumentationGenerator reports no change.

Known gap: the environment variable to static field path itself has no in-process test, for the parallelism reason above. The parsing is covered by unit tests, the wiring by the banned symbol, and the join by the manual build.

Documentation

A section in README.md and a new docs/generated-code.md covering what Roslyn considers generated code, the caching caveats (dotnet build-server shutdown, IDE restart, rebuild), and the generated_code = false .editorconfig alternative for users who want it per path and for all analyzers.