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.

Re-enable passing test TestFixAllInDocument_QualifyWithThis ( #320 )

Re-enable passing test TestFixAllInDocument_QualifyWithThis. Matt Warren fixed the underlying issue in SyntaxTree.GetChanges(SyntaxTree).

Make DiagnosticDescriptor completely exception safe ( fixes #887 )

reduce chance to report blank entries in error list.

correct text navigation in VB and C# strings

Made auto-properties readonly where possible.

Better handle dismissed rename tracking sessions

Support Introduce Variable refactoring in expression bodied members

Rename BitArray to BitVector to avoid conflict with System.Collections.B...

Generate DkmEvaluationResults asynchronously

Generate subsequent DkmEvaluationResults asynchronously rather than in the completion from previous DkmEvaluationResults to avoid stack overflow when many items are requested and evaluation is not already asynchronous (when EvaluateDebuggerDisplayString is not used).

Also added a smart, where, if we are in an expression bodied member context
and if the right side of arrow clause contains a block, we generate local
as if we're in a block context. This leads to an experience where we can
keep the expression body syntax and also have introduce a local (since we
have a block) without having to rewrite it to an equivalent full bodied
member whose body is always a block.

Move some more rules to System.Runtime.Analyzers

Address feedback from Tom: Ensure that we unsubscribe the exception handler registered with LocalizableString when the analyzer reference is disposed by the host. This will prevent statically instantiated LocalizableString instances from leaking the handler, and hence the analyzer instance.
We now have a public OnException event on the LocalizableString, which is invoked on exceptions. AnalyzerManager registers host's exception handler when populating descriptor cache per analyzer and unregisters this handler when host is disposing the analyzer.

Fixes #540 "Stale rename entries in the lightbulb menu"

Prior to this change, dismissed rename tracking sessions continued to
provide codefixes which would silently fail when invoked, without
completing the rename operation.

With this change, we now do the following when rename tracking is
manually dismissed:

- Trigger the diagnostic service to reanalyze the document, thus
removing the rename tracking diagnostic.
- Stop providing a codefix when requested
- Show a dialog if a cached codefix is invoked explaining that the
rename was not performed.

Here are the there user scenarios:

1. The user dismisses rename tracking

    - The lightbulb will continue to show in the margin, regardless of
whether any codefix/refactoring is actually still available.

2. The user expands the lightbulb without it ever having been expanded
before.

    - In this case, we are queried for fixes and will not return any, so
either the lightbulb will disappear or it will contain other relevant
codefixes/refactorings at that position, excluding rename.

3. The user expands the lightbulb after it was previously expanded.

    - Our fix was already cached, so we can only give a reasonable message
when it is invoked.

Once #885 is fixed, we can instead implement IDiagnosticUpdateSource and
avoid forcing diagnostic reanalysis.

Removes unused reference to BasicCodeAnalysis.Desktop.vbproj

removed skipped tests

Revert "Address review feedback from Heejae: add DiagnosticDescriptor.WithOnException to create a new descriptor with hooked up exception handler for reporting exception diagnostics from LocalizableStrings, instead of mutating fields of LocalizableString implementations."

This reverts commit 4e120580.

update unit tests to use localized resources and fix product code that wasn't

update unit tests to use localized resources

Interactive window updates

update Roslyn.Services.Editor.UnitTests.dll to use localized resources

update unit tests to use localized resources

Indent appropriately on Enter inside InterpolatedVerbatimString

Backspace completion should map the caret to the subject buffer

Address review feedback from Heejae: add DiagnosticDescriptor.WithOnException to create a new descriptor with hooked up exception handler for reporting exception diagnostics from LocalizableStrings, instead of mutating fields of LocalizableString implementations.

This is the final change in the series of changes I have been making to ensure that compiler and IDE are completely hardened against exceptions from analyzers.

This change makes the DiagnosticDescriptor completely exception safe. Currently, DiagnosticDescriptor has lazily evaluated LocalizableString fields for Title, MessageFormat and Description. These have public extension points at ToString, Equals and GetHashCode methods, all of which can throw. These callbacks have now been wrapped within a try-catch for our LocalizableResourceString implementation of LocalizableString. For custom user implementations of LocalizableString (which should hopefully be rare), we wrap these within an ExceptionSafeLocalizableString which calls into the inner localizable string wrapped within a try-catch. All this is done within the DiagnosticDescriptor constructor, none of the clients have to explicitly handle the exception at use sites.