Add support for extract method to work inside expression bodied members
and unit tests.

Adding additional errors for the Add Imports/Usings fixers to react to.
Now, when we get an error on an extension method we offer to import the
correct namespace.

Fixes #935
Fixes #562

Use the standard logic to determine whether to send enter through to the
editor, which requires using CSharpCompletionItems.

Fixes internal bug #1140893.

Fixes #1899

Consider the following case where M1 and M2 are non-existant methods -

this.M1(System.Exception.M2());

The code fix provider for generate method was offering two fixes to generate the method M1 above. Here's why. The fix provider gets called once each for the two diagnostics on the above line - the first with span corresponding to M1 and the second with span corresponding to M2. For the first span, the fix provider correctly constructs a fix to generate M1.

For the second span the fix provider correctly realizes that it can't construct a fix to generate M2 since System.Exception is a type from metadata and not source. However, looks like fix provider has fallback code to walk up the tree and see if there are other methods that it can construct in such cases. It ends up finding the InvocationExpression for M1 up the tree and therfore ends up returning another fix for generating M1.

I didn't want to change this fall back logic since it appears to be shared across multiple GFU fix providers and I didn't want to break other legit cases where this may be required for generate method.

Instead I am fixing this by introducing equivalence key for the corresponding CodeAction to ensure that the duplicate fixes will get filtered out when the light bulb presents the list of fixes in its UI. (This is identical to equivalence keys that we have in place for other GFU fixes such as Generate Type etc.). Note that we need the equivalence key for generate method anyways to avoid duplicate fixes in other unrelated cases such as following where M is a non-existant method -

var x = this; var y = this;
string.Format("{0}:{1}", x.M(), y.M())

Also, note that in some cases where we used to offer multiple valid fixes to generate methods with the same name but different signatures before, we will now only display one fix at a time. But this is fine since user can always fix first issue then invoke light bulb again to fix 2nd issue. Example of a case where there are 2 methods with same name but different signature -

this.M(this.M());

We use resource commenting "locked" to define what to localize.

Display a tooltip containing url destination for hyperlinks in the error list and light bulb preview pane UIs.

Also use full fidelity (i.e. substituted)  error message in the search query in the case of hyperlinks that redirect to bing search so that we can present more relevant search results.

- Fix #1853 update UnitTests to use resource strings
- Fix #1338 update EnC analyzers to use resource strings

Updates in this PR:
- Shared the same strings in FeaturesResources
- Added "Locked" annotation not to be localized

Fixes #29

Fix perf issue that was causing the tagger that's used in preview pane to unnecessarily peg CPU on UI thread. We were unnecessary cycling through all documents in a project when we only needed to process a single document.

Upgrades System.Collections.Immutable to 1.1.34-rc and
System.Reflection.Metadata to 1.0.19-rc.

These changes bring down the self-build of Roslyn.sln with Roslyn analyzers from 2x of the core build time (build with no analyzers) to ~1.15x on my box.

1) Parallelize compilation event processing: Currently, a single thread processes all compilation events. This is the primary bottleneck for 2x build time with analyzers enabled. However, now that multiple threads process compilation events and execute analyzers, we need to guard against actions running concurrently for the same analyzer instance via a lock. This is accomplished via creating unique gate objects per analyzer instance and locking on them. Deadlock is not possible as these are stored on a private map of the core AnalyzerExecutor, and analyzer callbacks cannot call back into the AnalyzerDriver.

2) Execute syntax node actions for every symbol declared event sequentially: Current approach executes node actions in parallel for different analyzers (though each analyzer's actions are always executed sequentially). Invariably, these action callbacks on different analyzers share the same semantic model, leading to lot of contention on bound node cache accesses, hurting the overall performance. Switching this to completely sequential execution model for each symbol declared event, along with optimization (1) improves the overall performance. There is scope to still fine tune perf here by executing actions with distinct {Analyzer, SemanticModel} tuple in parallel, but I'll leave that for a separate attempt.

First is cleanup some infobar code such as adding copyright header, adding internal, removing unused usings and etc.
Second is adding more info in exception log.
Last is making code action more resilient to null return value from user code.

When computing the distance between blocks, there was a missing case for LabeledStatement, causing UnreachableException. This PR fixes this issue.

Allow directive keyword recommenders to differentiate between the start
and middle of a preprocessor directive.

now, error list will have column (which is off by default) that shows source of each errors in a
format "assembly name" for analyzers node. and "assembly name" [vsix name] for vsix

Add simplifier annotation on using directives generated via the Add Using fix so that generated directives are already simplified (in the case where using is generated inside a namespace declaration) without the user having to simplify manually in a subsequent step.

Note: I also added the annotation inthe corresponding VB fix for parity. However, this should be a no-op for VB since VB only supports file-level namespace imports.

Fixes #1893

Make DiagnosticAnalyzerExtensions.GetDiagnosticAnalyzerCategory async to avoid force computing registered analyzer actions in the IDE.

1. When light bulb asks us for suggestions (i.e. in HasSuggestedActionsAsync() and GetSuggestedActions()), it also specifies the category of suggestions that it is looking for (code fixes, refactorings, anything etc.). So far, we were completely ignoring the requested categories. HasSuggestedActionsAsync() would always return true so long as we had a code fix (that is not a suppression fix) and GetSuggestedActions() would always return all types of suggestions (fixes, suppressions and refactorings) regardless of what the light bulb is asking for. This led to strange bugs where we would return refactorings even when light bulb didn't ask for them. In other cases, HasSuggestedActionsAsync() and GetSuggestedActions() would disagree for the same requested categories. This change makes things consistent so that we always honor the suggestion categories that the light bulb is requesting.

2. When computing refactorings we were completely ignoring the span specified by light bulb and only considering selection specified by user. This led to incorrect behavior in some cases - for example, on mouse hover over a squiggle, we would return the code fixes corresponding to the squiggle along with refactorings for completely unrelated portions of the code that the user may have previously selected.

Fixes #1030, #1595, #1631

Fix DiagnosticAnalyzerExtensions.GetDiagnosticAnalyzerCategory to return DiagnosticAnalyzerCategory.SemanticDocumentAnalysis if the analyzer has semantic actions and cannot support semantic span based analysis.

Fixes #1709

Fixes internal TFS bug 1142095

Commit any existing rename session when a document is saved or when
debugging run mode is entered. This ensures rename sessions are
completed before Edit and Continue sets the buffers to readonly when
debugging begins or when break mode is exited.

now, open files will prefer live errors over build errors and enqueue re-analysis right away

Add the complete exception stack trace to the description field of analyzer exception diagnostics. This will ensure that the stack trace can be viewed in the error list by expanding the diagnostic message.

Fixes #1444

Fixing Mef composition error caused by previous commit
(11a827c4)

Fixing Mef composition error caused by previous commit
(11a827c4)