This reverts commit d11147e2.

- Better comments
- Add named arguments

- Move the generated chek into the syntax tree
- Pass isGeneratedCode to both nullable directive map and warning state map
- When isGeneratedCode is true, add nullable disabled state to the start of the warning map
- Add extra tests
- PR feedback

Fix Formatting Warnings on Build

Include file counts in success message for dotnet-format

Handle ICoalesceAssignmentOperation in GetValueUsageInfo(operation) h…

Bail out on delegate creation wrapped a in tuple operation

Another case where we need PointsTo analysis for precise flow analysis, we bail out as we currently do not perform any PointsTo analysis.

Fixes #32903

Assert when emitting a box IL opcode for ref like type

Fixes #32842

Handle string concat with no string literals in ConvertToInterpolatedString

Avoid touching files that didn't actually change

Complete a number of nullable test issues

Localize regex tests

Fix formatting of positional patterns

dotnet-format --dry-run

Simulate the C# 7 compiler's behavior on traditional switch statements with old language versions (#32818)

Fixes #32806
This was a "forward compatibility" bug, where new compilers would accept code in old language versions that the older compilers would not have accepted.

Bail out on reporting unused parameter diagnostic for special paramet…

Update usages of the source file name when copying a banner to a new file.

Update System.Commandline in dotnet-format

Add Newtonsoft.Json dependency to dotnet-format

Co-Authored-By: Nsharwell <sam@tunnelvisionlabs.com>

closes #30767

closes #30755

closes #30754

The `MissingTypeKindBasisTypes` test is copied from `UseSiteErrorTests`
and given verification succeeds there it's reasonable to expect that it
would succeed here. However there are a few factors here that aren't
obvious at a glance.

The first is that not all of the compilations in `UseSiteErrorTests` are
verifable. The `compilation1` is not verifiable in either suite, it's
hard to miss because it's not tested. The reason why is that the corlib
reference name is mincorlib, not mscorlib. PEVerify is hard coded to
think the name of corlib will always be mscorlib. Hence any attempt to
verify against a different name corlib will always fail.

Well ... almost always. It fails only when it's used in the IL. For
`compilation2` there is no direct reference to corlib, hence mincorlib
doesn't appear in the IL and it passes verification. With NRT though we
silently emit an attribute in the binary for nullable tracking and this
does reference corlib (the attribute derives from `System.Attribute`)
and hence verification fails.

Adjusted the suite to make this expected.

closes #30747