Enable xaml project test

Fix ITypeSymbolExtensions.IsOrDerivedFromExceptionType to handle type parameters constrained on Exception type or its subtype. Fixes #3254 

Fix a NullReferenceException when setting diagnostic severity.

**Bug:** Fixes #3098.

**Customer Scenario**

1. Customer adds the NuGet package for Microsoft.AnalyzerPowerPack, System.Runtime.Analyzers, or System.Runtime.Interop.Analyzers (really, any package containing FxCop rules implemented as Roslyn analyzers).
2. In the Solution Explorer, the customer expands the References | Analyzers | Microsoft.AnalyzerPowerPack.Common node.
3. User right-clicks on CA2229 and selects "Set Rule Set Severity" | Error.
4. The effective severity of the rule changes to Error.
5. User right-clicks again and this time selects "Default" for the severity, intending to reset it to its default value.
6. The severity is not adjusted, and instead the following dialog pops up:

![image](https://cloud.githubusercontent.com/assets/235241/7825354/dbe7155e-03c0-11e5-819b-5beac1ffd2ad.png)

Note that VS does not crash, and after dismissing the dialog VS continues to function.

**Fix Description**
It is possible to have multiple `<Rule>` elements with the same ID in a
rule set file, so long as they specify the same Action. This is likely
to happen with former FxCop rules--you'll end up with one copy under the
"Microsoft.Analyzers.ManagedCodeAnalysis" analyzer (from FxCop) and one
under "Microsoft.AnalyzerPowerPack.CSharp" or similar (from a Roslyn-based
analyzer).

When the user selects one of these rules in Solution Explorer and sets
the severity to "Default" we need to find each rule with the matching
ID, and remove them all from the rule set file. However, we remove the
rules while we're in the middle of the enumeration, tripping up the
enumerator and leading to `NullReferenceException`s.

The fix is to first flatten the enumeration of items to be removed to a
list, and then remove them.

The first commit in this pull request implements the fix, the next two reorganize the code and add unit tests.

**Testing Done**
I added unit tests around the code in question, include one that fails without the fix.

I also ran through the scenario described above and validated that the rule set was updated as expected after I implemented the fix.

Replace public fields with properties in compiler API

Deal with solutions with circular project references in MSBuildWorkspace

Code Model: When setting the name of a CodeElement, ensure that its members are updated

Port PR #3237 to stabilization -- Catch exceptions when creating a stream for signing

Handle "Color color" from VB completion

Remove tail recursion and enable cancellation

Do not cut short binding of “return” statement even if expression has syntax errors.

Check current language version for “Global” keyword only if it starts namespace name in namespace declaration.

Update stabilization cibuild scripts

The cibuild scripts had diverged between stabilization and master. This
change brings stabilization back in sync with master and makes a small
change to ensure passing invalid commandline arguments returns a proper
error code.

If we have a solution with circular references, leave one as a metadata
reference to prevent deadlocks when trying to get compilations.

Fix ITypeSymbolExtensions.IsOrDerivedFromExceptionType to handle type parameters constrained on Exception type or its subtype

Fixes https://github.com/dotnet/roslyn/issues/3254

User scenario: User writes code where they have explicit casts to a type parameter deriving from Exception type or its subtype. We will offer incorrect cast removal fixes to remove these explicit casts. Removing such casts will cause their code to not compile. Even worse, if they apply a FixAll occurrences code fix, then all such casts across their (document/project/solution) will be removed, causing tons of compile errors.

Fix description: IsOrDerivedFromExceptionType was only checking for base types of the given type symbol to detect if the type is an Exception type. We also need to handle type parameters which are constrained by Exception or its subtypes.

Testing: Added regression tests + existing tests.

Add unit tests to cover modifying rule set documents.

Extract the code to modify rule sets to a helper type.

Addresses DevDiv 1179899.

Pass correct itemIDs to IVsSymbolicNavigationNotify

Fixes #3098.

It is possible to have multiple `<Rule>` elements with the same ID in a
rule set file, so long as they specify the same Action. This is likely
to happen with former FxCop rules--you'll end up with one copy under the
"Microsoft.Analyzers.ManagedCodeAnalysis" analyzer (from FxCop) and one
under "Microsoft.AnalyzerPowerPack.CSharp" (from a Roslyn-based
analyzer).

When the user selects one of these rules in Solution Explorer and sets
the severity to "Default" we need to find each rule with the matching
ID, and remove them all from the rule set file. However, we remove the
rules while we're in the middle of the enumeration, tripping up the
enumerator and leading to `NullReferenceException`s.

The fix is to first flatten the enumeration of items to be removed to a
list, and then remove them.

Loosen check in CapturedVariableRewriter.RewriteParameter

When we added support for transparent identifiers, we loosened the
existing check so that they wouldn't be flagged as erroneous.  We should
have gone further and indicated that all anonymous types (i.e. including
user-declared ones) are okay.

Because of the way its check is structured, VB is unaffected.

Fixes #3231

This change is meant to address crashes like the ones in bug 1140649. The
crashes seem to happen due to exceptions thrown while getting a temporary
output stream to write the PE file to. I have been unable to reproduce
the conditions for the crash themselves -- they only seem to happen on
a Japanese language Windows with a Japanese language copy of Visual Studio.
This fix addresses their symptom by wrapping the CreateInputStream call
during signing with a try/catch and then surfacing the exception as a
diagnostic for signing failure.

We cannot currently add any more localized resources to stabilization, so
this fix is meant to be as targeted as possible and can only deliver
information through existing resource strings.

(cherry picked from commit 801a10a5)

Fixes #3086.

Check current language version for “Global” keyword only if it starts namespace name in namespace declaration.

Addresses DevDiv 1129404.

Add unit tests for PR #3242 that correctly trigger the failure when the
change is not present, but pass when it *is* present.

Add an analyzer to catch incorrect usage of CodeAction.Create API for fixers that support FixAllProvider

Code Model tracks nodes with a "node key" concept, which is effectively
the full name of an element coupled with an ordinal. When the name of a
CodeElement is updated, its node key must also be updated since the name
of the underlying node has changed. However, we had failed to update the
node keys of any members of that CodeElement, which means that they can
no longer be located after their parent container's name changes. This
is now fixed.

Handle non-source file diagnostics in the VB command line diagnostic formatter

User scenario: A CodeFixProvider that supports fix all occurrences code fix, gets FixAll support in IDE if it registers a single code action, but disappears as soon as fixer registers multiple code actions.

Reason: A CodeFixProvider that intends to support fix all occurrences must classify the registered code actions into equivalence classes by assigning it an explicit, non-null equivalence key which is unique across all registered code actions by this fixer. This enables the FixAllProvider to fix all diagnostics in the required scope by applying code actions from this fixer that are in the equivalence class of the trigger code action.
The analyzer added by this change catches violations of this requirement in the code actions registered by a CodeFixProvider that supports FixAllProvider.

Fixes #2864

Ensure SemanticModel reports node as a default instance access rather than as a type reference, when the type reference is reclassified as such.

User scenario: User compiles a project with analyzers, and analyzer(s) generates a diagnostic with location in a non-source additional text file, but msbuild doesn't report such analyzer diagnostics and exits with code 1 with no output.

Bug description: For analyzer diagnostics in additional file, VB command line compiler doesn’t output any file information or squiggles. However, it does include the file name and location in the output. This format doesn't match the Vbc MSBuild task parsing logic which expects the output to have either all of this information (file path, location, file content and squiggles) OR none of it for no-location diagnostic. This causes the Vbc task to ignore additional file diagnostics.

Fix description: Fix the VB command line diagnostic formatter to always output diagnostics in either of the above 2 formats expected by MSBuild. For additional file diagnostics, the formatter now attempts to read the additional file stream and if it succeeds, formats it as a source diagnostic with location info and squiggles. Otherwise, it formats it as a no-location project diagnostic.

Testing: Added regression test + existing tests. Also verified that the original issue reported on Roslyn.sln is also fixed by this change.

Partial fix for internal TFS bug #1169405

We previously always passed Nil for all itemidCodeFile parameters in
IVsSymbolicNavigationNotify to ensure the XAML language service heard
our request (because their current implementation only processes request
for Nil or 0-valued itemids.) This caused Go To Definition and Find All
References to be slower than necessary in non-XAML cases and also
resulted in unwanted behaviors on certain properties that are referenced
in XAML.

Our two options for fixing this were to either:
1. Update our implementation to send the correct item ids for
heuristically "non-generated" files and send Nil for "generated" files
(to match the Dev12 behavior)
2. Always send the actual item ids, even for "generated" files, and
update the XAML language service to do a fast initial check of the
corresponding document to see if they're interested in processing it.

This changeset represents the Roslyn half of option 2. Any builds that
contain this fix but do not contain the corresponding change to the XAML
language service will see no Go To Definition navigation to .xaml files
(e.g. when navigating from a reference to a named Button) and no .xaml
file entries in Find All References.

Unfortunately, this does not remove all heuristics from this algorithm,
because Roslyn must still decide which itemid to pass in the case of a
definition spanning multiple documents (e.g. the MainWindow class
created in default WPF projects). We always prefer the "generated"
documents to give external language services the best opportunity to
participate.

If IVsHierarchy.ParseCanonicalName returns something other than S_OK,
then use VSITEMID.Nil