Add a doc about the change in unicode version.

Remove Logger and RoslynCompilerEventSource

Move VSTelemetryLoggerTests to a closed source test project

FakeSign the concord binaries

support compilation end action in v1 diagnostic engine

Disable the UnusedDeclarationsAnalyzer by default

Run FakeSign.exe on the concord binaries that we import as IL and
re-assemble ourselves.  This makes it possible to load them in
CI builds on Jenkins.

CR: @jaredpar; @jasonmalinowski

Related to issue #1058.

The analyzer reports thousands of spurious errors when running over
Roslyn.sln. In order to move forward to newer builds of the toolset
compilers and diagnostics, it needs to be disabled.

Expand root-level synthetic IEnumerable values without an intermediate "Results View" row

Removing the intermediate "Results View" row for synthetic values allows LINQ queries to be expanded automatically in the Immediate Window.

Improve Encoding support in SyntaxTrees and Documents

I went thorough v1 diagnostic engine to fully support compilation end actions.

now it should properly cache and report errors to associated services when there is compilation end actions registered.

but admittedly I didn't tighten it as much as I can assuming all these will change once we move to v2. but this should do its job.

Fix execution of CompilationStartActions when only analyzer options for the project change, but the underlying compilation is identical.

Our current assumption for executing CompilationStartActions is that they should be executed exactly once per-compilation per-analyzer. We cache the registered nested actions for every compilation in AnalyzerManager to ensure this. However, if user just changes an additional document for the project, then the analyzer options change, but the underlying compilation is unchanged. Project change causes IDE diagnostic service to clear all cached diagnostics, but when re-computing diagnostics, we end up skipping execution of CompilationStartActions and directly move to nested compilation actions. This can be troublesome in couple of ways. First, we will have duplicate callbacks for all nested actions for the initially invoked compilation start action. Second, and event worse, if the analyzer is reading the contents of the additional documents in the start action and caching them for later use by the nested actions, all the nested actions get stale contents for the additional documents. Apparently, Tom is the first one to go through this agony as the DeclarePublicAPI analyzer that he implemented exactly does the latter.

Fix is to ensure that we execute compilation start actions for every unique compilation start analysis context, i.e. {compilation, analyzer options} tuple for every analyzer. This change fixes #530 

Simplify GetEvaluationResultsAndContinue...

Enable EnC for C# methods containing lambdas and closures

I *think* this should behave the same.  We can remove the range check in the lambda and just call GetEvaluationResultsAndContinue again with "index + 1".  The outer if should catch the index >= numRows case and call the completionRoutine.

Address CR feedback from Heejae: Avoid unnecessary IEqualityComparer<AnalyzerAndOptions>, set concurrency level for concurrent dictionary, and add early out checks based on reference equality in added Equals overrides.

Copy ResultProvider sources, rather than binaries

Make ExpressionCompiler and ResultProvider public...

Looks like some of the MSBuild files got checked in under Src instead of
src.  This corrects that.

closes #1045

fix missed or incorrect localized strings in tests

Reflection APIs used by the dispatcher to create these classes may not be available on all platforms.

We need to produce two copies of each ResultProvider DLL, one that runs on
NetFX20 and one that is Portable.  We originally believed that we could
create a single DLL that would work for both and so we just copied the
output of each ResultProvider project and signed it with a different
Authenticode certificate.  Now we know that - even though the source of
both versions will be the same - we need to actually recompile for
Portable.

As a first step, we eliminate the copying mechanism and split each
ResultProvider project in two.  To minimize duplication, we introduce
shared projects that hold on to most of the source.

The next step will be to make the two copies reference different
assemblies.

Clean up Solution Explorer context menus

Fix issue introduced by recent change that breaks web scenarios

If the user selects a bunch of diagnostics with differing severities in
Solution Explorer, right-clicks,  and opens the "Set Rule Set Severity"
submenu they will see a check mark next to every applicable severity.
E.g., if one rule is an error and one is a warning, then both Error and
Warn will be checked.

The general feeling is that this will be confusing to users. Instead,
only show a check mark when all the selected rules share the same
severity.

Of course, a ContainedLanguage will never be an IProjectionBuffer. So,
this method always returns an empty enumerable. Instead, the cast should
be against _containedLanguage.DataBuffer.

#hangsheadinshame

Fix execution of CompilationStartActions when only analyzer options for the project change, but the underlying compilation is identical.

Our current assumption for executing CompilationStartActions is that they should be executed exactly once per-compilation per-analyzer. We cache the registered nested actions for every compilation in AnalyzerManager to ensure this. However, if user just changes an additional document for the project, then the analyzer options change, but the underlying compilation is unchanged. Project change causes IDE diagnostic service to clear all cached diagnostics, but when re-computing diagnostics, we end up skipping execution of CompilationStartActions and directly move to nested compilation actions. This can be troublesome in couple of ways. First, we will have duplicate callbacks for all nested actions for the initially invoked compilation start action. Second, and event worse, if the analyzer is reading the contents of the additional documents in the start action and caching them for later use by the nested actions, all the nested actions get stale contents for the additional documents. Apparently, Tom is the first one to go through this agony as the DeclarePublicAPI analyzer that he implemented exactly does the latter.

Fix is to ensure that we execute compilation start actions for every unique compilation start analysis context, i.e. {compilation, analyzer options} tuple for every analyzer.