changed sign method from vsix to vsixSHA2

Prevent spurious warnings about missing dependencies.

**Bug:** Fixes #3020.

**Customer Scenario**
1. User adds any analyzer assembly that includes a code fix to their project (e.g.,  Microsoft.CodeAnalysis.FxCopAnalyzers.dll or Microsoft.CodeAnalysis.CSharp.FxCopAnalyzers.dll).
2. Users saves their project and restarts VS.
3. User reopens the same project.
4. User gets spurious warnings about 'System.Composition.AttributedModel' not being found and analyzers possibly not working. Closing and reopening the project sometimes helps, but more often than not the warnings show up.

**Fix Description**
The fix updates the `AnalyzerDependencyChecker` to allow whitelisting arbitrary sets of assemblies, not just those already loaded. This is used to then whitelist all assemblies with a name starting with "System" on the assumption that even if they are not already loaded they will in fact be found if needed. If an analyzer reference appears on any whitelist we won't report it as missing, even if we don't know where it is.

**Testing**
I tested the customer scenario listed above, and also tested that missing assemblies that *don't* start with 'System' as still reported.

Respect ParamArray attribute in source on a delegate parameter.

Fix DataTips in Web apps...

(fixes #2916)

We were previously attempting to match spans in the subject buffer with "Length == 1".  This was incorrect, because the input span is always expected to be zero length in GetDataTipText.  I've fixed the check and added an Assert to this effect.

Remove an unused test resource.

Reload analyzers with loading errors.

**Bug:** Fixes #2707.

**Customer Scenario**
User adds an analyzer to their project in VS without first adding all of the dependencies. E.g., they add Microsoft.CodeAnalysis.CSharp.FxCopAnalyzers without first adding Microsoft.CodeAnalysis.FxCopAnalyzers.

The Error List will show various warnings about missing analyzer assemblies and being unable to load diagnostic analyzers from Microsoft.CodeAnalysis.CSharp.FxCopAnalyzers. This is correct and expected.

The user then adds the missing analyzer assembly, expecting the warnings to go away and the diagnostics to start working. Instead, the warnings remain, and the diagnostics still do not work.

**Fix**
The issue is that an `AnalyzerFileReference` only looks for
`DiagnosticAnalyzers` once, and caches the results. So even though we
add the missing dependency and *could* load the types, we don't actually
try.

The fix is in the logic to add a new analyzer assembly in VS. In
addition to pushing a new `AnalyzerFileReference` down to the workspace,
we examine the list of existing analyzers. For each one with load
errors we remove the existing `AnalyzerFileReference` and add a new one.

**Testing**
I ran through the Customer Scenario described above.

renaming props files

renaming the fxcop binaries and making them portable.

Stabilization Port -- NavBar: Guard against symbol navigation on non-symbol items

Fixes internal TFS bug #1174848

When a Navigation Bar item is chosen, like the NavigationBarSymbolItem
representing a particular member, we present the set of chosen items
(for project, type, and member) as base NavigationBarItems with the text
display properties & tracking spans *copied* out of the real
NavigationBarSymbolItem to remove any display indentation and to make
sure the Navigation Bar does not hold on to old symbols, etc.
When the Navigation Bar is expanded, we present real
NavigationBarSymbolItems again and when they are chosen we perform the
appropriate symbolic navigation.

However, there is a moment after an item is chosen where we have
replaced the real NavigationBarSymbolItem with its NavigationBarItem
copy, but the Navigation Bar is still allowing clicks to the item to
count as navigation (rather than expansion of the collapsed list). When
this happens, we see NavigateToItem called on a base NavigationBarItem
and crash because we believe it will be a NavigationBarSymbolItem.

The base NavigationBarItem was being used for multiple purposes, so this
change makes it abstract and introduces NavigationBarPresentedItem for the
purposes described above and NavigationBarActionlessItem which can be used
for items that legitimately produce no action when selected (used in some
VB event scenarios). The NavigationBarController now rejects any attempts
to select a NavigationBarPresentedItem so that the
INavigationBarItemService implementers will not have to deal with them.

VB was already avoiding this problem by typechecking the
NavigationBarItem, and this change also applies the same type check to
C#.

Revert "Make MetadataReference.CreateFromAssembly obsolete"

This reverts commit e16d38bc.

Fix connection issues in server

This addresses the following issues:

- GitHub #2866: Asserts in the check connection loop.
- DevDiv 1175084: Crashes when server is unable to complete the connection to the named pipe.

These issues are being addressed together because they stem from the same
underlying problem.  The code is not fulfilling two of the main invariants
of connection processing in the server:

- The `Task` representing a client connection should never throw an exception.
Failed connections are instead represented by the data returned from the `Task`.
- A connection should always provide a new timeout value before completing the
compilation process.

The `Connection` type is responsible for the majority of the processing here
and is careful to maintain these invariants.  The `ServerDispatcher` type though
didn't fully account for exceptions.  This meant that errors actually completing
the `NamedPipeClientStream` connection ended up violating both of the core
invariants.

The solution here is two fold:

1. Properly handle the exceptional cases that can come from completing the named
pipe connection.
2. Use a single `Task` to represent a client connection instead of a separate one
for the compilation and keep alive.

close #2866

Improve handling of My.InternalXmlHelper

NavigateTo shouldn't consider generated files.

Do not run through following phases in Rewriter.LowerBodyOrInitializer once errors are encountered.

Import parameter's default constant value from metadata even if parameter is not optional.

Make MetadataReference.CreateFromAssembly obsolete

Dont auto-format some keys when smart indent is off

Support multiple kinds of whitelists in the `AnalyzerDependencyChecker`.

Right now the `AnalyzerDependencyChecker` takes a whitelist of
`AssemblyIdentity` as an argument; if an assembly is on this list, we
won't report it as missing when checking that all of an analyzer
assembly's references are present. In practice, VS passes in a list of
all the currently loaded assemblies when running the checker.

However, it is possible that an analyzer assembly has a reference that
VS could satisfy but it simply isn't loaded yet. For example, I've seen
warnings that System.Composition.AttributedModel can't be found, even
though it ships with VS. There's no reliable way to make these warnings
go away.

To fix this, this commit introduces an abstraction,
`IAssemblyWhiteList`, and two implementations. The first,
`AssemblyIdentityWhiteList` simply repackages the functionality we
already have, taking a list of specific `AssemblyIdentity`s. The second,
`AssemblyNamePrefixWhiteList`, whitelists every assembly whose name
starts with a given string.

VS uses these to whitelist all the loaded assemblies along with all
assemblies that start with the name "System". This brings VS in line
with the checks done in VBCSCompiler.exe.

...as in Dev12.

Harden access to MetadataReader

Skip over partial methods with no implementation when emitting extra …

C# EnC: handle addition of indexer

Also add a check that the span returned by
`ISyntaxFactsService.TryGetDeclaredSymbolInfo()` in SyntaxTreeInfo is valid.

Two things were preventing the EE from finding the type, which is needed
for XML literal operations in VB:

1. It is marked internal and the accessibility check happened in
AssemblySymbol, rather than the binder, so it was not hijacked.

2. It is marked with EmbeddedAttribute and is not from the SourceModule of
the compilation (it's from the module of the current frame).

We can resolve both of these problems by doing the lookups as though we
were in the module containing the current frame.  This required two
changes:

1. Remove InternalXmlHelper from WellKnownTypes and give it its own code
path.  Explicitly pass the appropriate module symbol to the new helper.

2. In Binder.CheckViability, look for a containing module before falling
back on the SourceModule of the compilation.

By preserving the accessibility checks during type lookup (but doing them
from the perspective of a different assembly), we retain the compiler's
protection against pulling in a copy from each VB reference (i.e.
ambiguity).

The main caveat is that My.InternalXmlHelper will not be found if it was
not embedded in the module containing the current frame - even if it is
unambiguously available in a referenced assembly.

Breaking change: unlike dev12, roslyn will only find My.InternalXmlHelper
in the source module.

Fixes #964