* dotnet/master: (61 commits)
  Suppress xlf on templates.csproj
  Fix the MSBuild syntax error
  added a way to set logging information synced to remote host and more logging for error list. (#23614)
  Revert "Merge pull request #23364 from tmat/DisableBackgroundCompiler"
  Reduce the number of attributes that should be bound in order to determine if there are NoPia local types explicitly defined in code. (#23505)
  Fix microbuild for VBCSCompiler
  Avoid using PerformanceSensitiveAttribute in pooled object types
  Testing theory about %TEMP%
  Move C# tests to testing metadata emitted attributes through `CompileAndVerify` (#22896)
  Fix xml doc files
  we called work done too early. (#23623)
  Test theory new props caused int failure
  Add VBCSCompiler.dll to the Microsoft.NETCore.Compilers package
  Further isolate our msbuild test files
  Deploy Dir.build.props / targets in tests
  Fix deployment of ilasm
  Fix publish dir name when no runtime identifier
  Generate xml doc files during build
  Fix publish to include runtime identifier in dir
  Remove unneeded file SettingsSdk.props
  ...

Move to minimal MSBuild syntax 

The templates project was not being picked up by xlf previously due to
resx files being included in `<None>` items in the project file. Once we
moved to the new SDK here they were turned into resources by virtue of
the EnableDefaultEmbeddedResourceItems property. Disabling that for now
as it gets us back to the state before this change. Filed a bug to track
re-enabling it at a later time.

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

Need to wrap the property group in the test Directory.Build.props file
with a PropertyGroup.

added a way to set logging information synced to remote host and more logging for error list. (#23614)

Revert "Merge pull request #23364 from tmat/DisableBackgroundCompiler"

This reverts commit 80d79c40, reversing
changes made to 37ef0cde.

General improvements to Linux story

Fix flaky compiler server test

Optimize ArrayBuilder<T>.ToImmutableAndFree

Reduce the number of attributes that should be bound in order to determine if there are NoPia local types explicitly defined in code. (#23505)

Fixes #23179.

Add VBCSCompiler.dll to the Microsoft.NETCore.Compilers package

Perform a lightweight syntax check before getting document options

VS should be inheritting the %TEMP% value we are setting. On the off
chance it gets the original value though lets copy the props / targets
files there to see if this is the cause of the hang.

* Refactored synthesized attributes tests

* Remove rest of calls to CompilationUtils.GetSynthesizedAttributes()

* Fix EE tests

* Fix [Dynamic] tests

* Clean up

* Remove EmitMetadataTestBase.ValidateDeclSecurity(Compilation)

* Remove C# GetDefaultPEBuilder

* Fix Assembly Attributes tests

* Clean up

* Address PR Comments

* Clean up

The XML doc files for multi-targetted builds were clashing with each
other. Both were being written to the raw obj directory. Needs to be
written to the obj directory with the target framework suffix to avoid
the clash.

previously, we set all work as done when we pass out last work from the queue without waiting that work to be done.

now, we raise works as done only when last item passed out are actually done.

Mark Toolset projects non-shipping

This disables a number of places where local developer state could
influence the result of our MSBuild tests. These are locations where
MSBuild will wildcard import any files it finds. Using the test
Directory.Build.props file to disable all these extensibility points.

Our MSBuild tests layout project / solution files on disk and then uses
MSBuild to evaluate them. During this evaluation MSBuild will search for
Directory.Build.props / targets files on the path just as it will for a
normal command line build.

On Jenkins our Directory.Build.props / targets is in the search path of
MSBuild and gets picked up during testing. This was causing our tests to
fail as we unconditionally override a number of properties in our core
targets files.

To insulate against this we now deploy and empty version into the
directory where we generate our solutions.

The assembly name of the deployment project was clashing with the ilasm
exe we were trying to deploy. Gave it an explicit name to remove the
clashing values.

Needed to specify the targetframework portion of the path in the same
way we specify the runtime identifier portion. Should get simpler when
we just embrace the layout the SDK is aiming for here.

The publish directory needs to have the runtime identifier prepending to
the publish directory name. Previously out setting of `<OutputPath>`
happened early enough that the default logic kicked in. Now though it
happens too late. Copied the logic which used to set this for us and
filed a bug to undo all of this later.

This is a standard tool in our repo. Looks like it was just omitted by
accident when it was originally authored.

Our project files are now a mix of empty XMLNS and official MSBuild
XMLNS. BuildBoss needs to handle both cases.

The combination of the minified MSBuild syntax and Directory.Build.props
/ targets file will change when in the build process our central build
files are executed. For instance Imports.targets will now be run much
later in the build after Sdk.targets. Where before, when it manually
invkoed Sdk.targets it was able to run both before and after it.

To keep our build functioning the same way we need to move around some
of the logic within our build files so that it executes in the same
relative order as it did before

The build system used to allow projects to opt out of anaylzers by
setting the property `$(UseRoslynAnalyzers)` to false before importing
Settings.props. This meant it occured at the top of the file above all
other elements, including the main property group block.

This doesn't really have an equivalent approach in the new SDK. There
is no way to pass a property value from the project file to the
Directory.Build.props file as it's implicitly imported.

The correct approach in the new SDK would be to do the following:

1. Define `$(UseRoslynAnalyzers)` in main property group block
1. Use the Roslyn analyzers as a `<PackageReference>` declaration in the
`Imports.targets` file and have it condition on `$(UseRoslynAnalyzers)`
not being false.

Doing that is a pretty siginificant rework of our build though. As a
test I just disabled the analyzers everywhere and found we had a total
of three warnings. Decided to just fix those as it was very straight
forward to do.

It had conflicting TargetFramework and OutputType annotations