Check analyzer consistency after solution load.

Right now we only invoke the `AnalyzerDependencyCheckingService` when
explicitly pushing a change in the set of analyzers down to the
workspace. As we batch up all changes during a solution load and wait to
push them to the workspace once at the end, we end up skipping this
check until the next time the user adds or removes an analyzer.

This change causes us to explicitly run the check when solution load
completes.

This commit updates the `AnalyzerDependencyChecker` type to reflect the
recent changes to require all analyzers and dependencies to be
specified, and the changes in how we load analyzer assemblies.

Now that we require all analyzers and dependencies to be specified, we
no longer look next to the specified analyzers to optimistically locate
dependencies. Instead, we only consider the list of passed-in analyzers
*plus* the assemblies already loaded into the `AppDomain`. The latter
avoids unhelpful warnings in the event that the analyzer assembly
includes a code fix that take a dependency on a Visual Studio assembly,
which of course can't be included in the list of analyzers. We now
create a warning when we identify a missing dependency.

We now also check analyzers themselves for conflicts (i.e., assemblies
at different paths with the same identity but different contents)
instead of just their dependencies.

Remove duplicate sequence point and unnecessary nops emitted to VB iterators

Delete unused Desktop assemblies

This deletes the empty and unused Desktop assemblies from the code base.

Right now the IDE uses the Csc/Vbc host objects from the build
task by loading the task from the GAC (since the task is only
installed in the MSBuild directory otherwise). However, this breaks
using a different task for ETA tests since the GAC will always
take precedence.

This change adds the build task to the VS setup to include the
task in the IDE installation.

Fix issue with C# character literals in InitializeComponent() method

Suppress a false positive error reported by FxCop

FxCop is currenly reporting a false positive error for calls to XmlReader.Create() in projects that compile against the .NET portable (core) framework. Suppress this error until the rule owners fix the rule to account for portable framework.

Fixes internal bugs 1169525, 1169526, 1169527

fixed crash due to null project id

Refine construction of DynamicFlagsCustomTypeInfo

Separate factory methods for each of the projects that consumes it and a
little less copying.

Expand transparent identifiers in the EE

EnC: Renaming captured variables is rude

Generalize assert to include source statements that result in bound try

...the same way we expand display classes and state machines.  If we see a
local or parameter with a transparent identifier generated/mangled name,
we should instead include the properties of its (anonymous) type in our
list of bindable symbols.

Points of interest:
1. Transparent identifiers can be chained (i.e. have transparent
identifier properties).
2. Transparent identifiers can be captured (i.e. they might be display
class fields, rather than locals or parameters).
3. Display class instance locals cannot appear within transparent
identifiers (i.e. the recursion goes in only one direction).
4. For the benefit of the debugger, we're actually using fields, rather
than properties.  As a bonus, this was more consistent with the display
class case and, therefore, easier to implement.

TODO: Make a (hopefully) similar change in VB.

we forgot to add null check before calling GetProject

EnC: Fix mapping of variables declared in lambdas.

Enable test filtering with wildcards

Bug2435

Fixes #2567

Replace public fields with properties in Microsoft.CodeAnalysis

Fix an InvalidCastException in simplifier.

msbuild /m BuildAndTest.proj /p:IncludePattern="*Compilers*UnitTests*.dll"

Unskip a couple tests that now pass on 64-bit...

Add support for explicit interface members in DocumentCommentId

Handle converting between interface implementation kinds

Fix elastic formatting rule with comments

Do not throw if paths are bad

Fix alpha-substitution for nested lambdas in a generic context.

Remove code from Workspaces.VB/C#.Desktop