The [change](https://github.com/dotnet/roslyn/commit/6be56fadb4c417c4b6af0bf62f1242e41c8dd124) to move analyzers to 2.5 version broke analyzers in the branch - they are laid out differently in the new nuget package. Build targets are unable to find the props for importing the analyzers and silently bail out executing them. This PR fixes the following:

1. Fix the props file path in Imports.Targets
2. Move to a newer analyzer package which has an important [bug fix](https://github.com/dotnet/roslyn-analyzers/pull/1255)
3. Report a build error if analyzer props file does not exist
4. Fix the public API errors (mostly due to duplicate entries in shipped and unshipped files).
5. Fix one instance of RS0014 (Do not use Enumerable methods on indexable collections. Instead use the collection directly) introduced recently in the code.
6. Add suppression for one instance of CA1802 in WellKnownAttributeData.cs that fixed the signing issue.

This change is required for accurate handling of comments, per dotnet/roslyn#2773.

The NuGetPackageToIncludeInVsix element is used to make the NuGet assets
we use in a VSIX very explicit. It depended on the nuget items having
the metadata element NuGetPackageId. The 1.X New SDK no longer has this
piece of metadata and hence we had to pick a new approach.

After some discussion decided to simply look for the assets which are
coming out of the NuGet packages folders that we expect. It's
essentially the same check.

Needed to encode this in an MSBuild task though as the MSBuild
transforms can't handle that level of complexity.

The warning B40057 used to be suppressed at a global level in PCL /
Desktop projects. The SDK does not suppress this warning and hence
converting to the new SDK caused this to show up.

Previously a number of developers fixed this problem individually. The
correct solution is to suppress it globally as was done previously.

Couple of changes to make it possible to build all desktop projects on
new SDK

- Use new RunResolvePackageDependencies target
- Use LangaugeTargets to allow WPF / VSIX to be built

Enable few more rules and fix issues identified these rules.

Also added issue IDs for the disabled rules due to lack of a fixer/fix all experience.

The new SDK unconditionally sets a number of MSBulid properties
including many that we depend on in Roslyn.  This is a break from the
old MSBuild behavior which respected initial values.

https://github.com/dotnet/sdk/issues/752

The behavior in 2.0 is changing to go back to the old model of
respecting initial values.  Roslyn though continues to often use the SDK
installed with Visual Studio.  That can be a variety of values from 2.0
prebuilds, to various drops of 1.0.

As a result the success / failure of our build can depend a lot on which
version of VS is installed and by consequence which new SDK comes with
it.  Subtle differences in the SDK can change the values we end up
compiling with in our project.  We've been guarding against this
by directly re-setting values we knew to be overidden in some version
of the SDK.

Now though I'm worried this isn't an adequete solution for the following
reasons.

- Just this week I got new warnings in the build by using a new VS
- The Microbuild lab is aggressively grabbing new builds of VS which
means the VS SDK is also potentially changing.

After some thought I decided to simply move all of our langauge specific
settings after we import the core targets.  Given that we
unconditionally set the values it becomes irrelevant what the SDK does
or does not respect.

This is a workaround for dotnet/project-system#2160 where
AdditionalFileItemNames isn't quite behaving correctly with the IDE.
This can be reverted once that bug is fixed.

* Update toolset compilers to 2.3.0-beta2-61716-09. Use LangVersion=7.1
* Revert LangVersion for VB. Follow-up issue #19610

Re-enable roslyn analyzers on Roslyn.sln and update public api file for an IOperation API change merged yesterday (#19278).

The VS SDK team is interested in tracking down the deployment errors
that we are seeing when deploying as a part of build.  This change adds
an option to make it easy to excercise that code path in builds.

Going to use this option to quickly toggle to the build based deployment
in order to mass test their fixes.

The Net20 framework projects were accidentally depending on 3.5
framework in order to build.  This is due to how they generate
resources.

By default when generating resources for a 2.0 framework project the
MSBuild task from 3.5 was being used.  This is not installed by default
with Visual Studio and only through the 3.5 framework.

This went unnoticed when moving to the new SDK because all of the
Jenkins machines and @jaredpar machines have it installed.

Setting the `$(GenerateResourceMSBuildRuntime)` property to
CurrentRuntime will use the GenerateResource task from the current
version of MSBuild.  This is how resources were being generated before
the migration.

The content produced by NuGet restore is independent of build
configuration.  Hence it needs to be stored in a folder that is
accessible to both Debug and Release.

This didn't work with the present structure of our Obj directory
because it put project folders under configuration directories.  That
mean there is no common parent for a project across all configurations.
To fix this we need to change our Obj structure:

- Old: `Obj\<Configuration>\<Project Name>`
- New: `Obj\<Project Name>\<Configuration>`

This changes our NuGet download and commits us to package reference
elements.

My motivation for doing this is to pick up the new PublicAPI checker
that understands type forwards. In doing so I disabled a bunch of new
warnings that are either broken or not really applicable to Roslyn.
One new warning (don't rethrow exceptions with throw ex;) seemed useful
enough to keep on so I left it on and fixed the one offense in the
codebase.

Based on discussions with SDK team, attempting to switch to using
`$(OutputPath)` for controlling our output directory instead of
`$(OutDir)`.  This is how the SDK recommends teams do it and need
to validate whether this will work for us or not.

The motivation for this change is to simplify our build and develop
steps.

Previously our compiler builds included files generated into the Obj
folder during previous phases of the build.  This meant that in order to
open Roslyn.sln successfully the code needed to be built first.  Not
ideal.

The generated code involved is rarely changed.  But in order to build
the generators themselves must be built and run as a part of every
build.  This is doable but adds unncessary overhead to development and
complicates our build files a bit.

This approach checks in the generated files which should have the
following benefits:

- Roslyn.sln can be open after a restore
- Build process is simplified and marginally faster for many operations
- Generated code now participates in GitLink

Removes our reliance on the machine installed reference assemblies.
Preferring the ones which we bring with us to the machine for both
Windows and Linux.