Fixes #37224
Fixes #37268
Fixes #37361

Update ownership of CompilerGeneratorTools to the compiler team

Disable interprocedural dataflow analysis for DisposableFieldsShouldB…

Otherwise the infrastructure team gets tagged and that's not useful.

This should fix the performance issues reported in VS feedback tickets [#672009](https://developercommunity.visualstudio.com/content/problem/672009/live-analysis-eats-up-memory-resulting-in-vs-crash.html) and [#672909](https://developercommunity.visualstudio.com/content/problem/672909/live-code-analysis-extremely-slow-and-vs-2019-cras.html)

Explicitly call BindExpression in GetSpeculativeSymbolInfo, instead o…

Use MaxSupportedLangVersion in CSharpUpgradeProjectCodeFixProvider

Update CODEOWNERS

Handle speculation for AsNewClause by generating an EqualsValue node

Fix our MSB3270 warnings

Publish Ngen logs separately

Consume the new IMethodSymbol.Construct overload that takes nullability

Merge release/dev16.3-preview2 to master

Adding Skip to CSharpInteractiveCommands.VerifyPreviousAndNextHistory

https://github.com/dotnet/roslyn/issues/18779

Formatting updates for C# 8

We don't have any groovy scripts anymore.

The type inferrer does method type inferrence if we know what the
return type of the method should be. This triggered if the method was
handled an argument which it could then chase up and find the
InvocationExpressionSyntax. Unfortunately if you are inferring and
don't have an argument you still want to be able to infer the type
of the argument if there was one there, but there's no ArgumentSyntax
to work from. Thus, it's easier to just directly pass the
InvocationExpressionSyntax and avoid the tree walk; looking through
the callers of InferTypeInArgument there's only one place where
it could potentially find an InvocationExpressionSyntax, and that one
place is the place I updated the call site on.

There are a few parts to this change:

1. Ensure that MSB3270 and MSB3277 warnings are promoted to errors in CI
and hence block merging.
1. Move our DiaSymReader.Native logic into a separate targets file.
This resource cannot be consumed with a simple package reference but
rather requires a package reference and custom logic to pull out the
contained binaries. This logic used to be spread through our build. Now
it's in a single place.
1. Remove the x86 bootstrapping logic. This was testing a pretty obscure
scenario and the cost of maintaining that logic is siginificant at this
point. Can bring back if we ever find a bug in this area.

The root cause of the MSB3270 warnings is a subtle change in the SDK. It
now passes the runtime graph to NuGet for native assets. In the case of
DiaSymReader.Native there are runtime specific assets hence the SDK /
NuGet had to pick one for framework projects. This eventually lead to
`PlatformTarget` being set to x86 where it shoud have been AnyCPU.

Part of the change includes adding `ExcludeAssets=all` to the package
reference which means they no longer figure into this logic and hence
the binaries are marked as AnyCPU.

This regression in behavior is being tracked by
https://github.com/dotnet/sdk/issues/3495

Move comment to correct line of code

The NGEN log files are published inside our "Build Diagnostic Logs"
container today. That is regularly around 160MB in size of which the
NGEN logs take up ~700K.

Been working on some automation / processing that is specific to NGEN
log files. Downloading the other 159MB is fairly wasteful and slow for
this automation. Publishing the NGEN files separately so I can make this
automation more effecient.

Merge release/dev16.2 to release/dev16.3-preview2

Update LanguageServices dependencies