Fixes #2605 "Lightbulb suggests renaming a type to 'var'"

This change disables using Rename Tracking to rename to/from "var" and "dynamic" in C#.

Fixes #2623

Fixes #2232

Prevent crash by avoiding QualifiedName->PredefinedTypeName simplification inside QualifiedNames.

This reverts commit cdf6029c.

Fixes bug #2516 by mapping the new caret position to the correct buffer when Home/End is pressed during InlineRename. This change also avoids exceptions when we fail to map the selected spans down to our buffer when Inline Rename is invoked.

Fixes internal TFS bug #1027506 "Rename: No unresolvable conflict shown
for interface/class name conflict"

Update the ConflictResolver to catch declaration conflicts between types
of different kinds (classes versus interfaces) and between types &
namespaces. When two different kinds of types conflict, the conflict is
shown on the one that's not currently being renamed. When a type
conflicts with a namespace, the conflict is always shown on the type.

This is cleanup from DevDiv #1043494.

Assert if we are not on the UI thread and give test authors the choice
to explicitly pass in the default namespace.

Fixes internal TFS bug #1114858

The HACK_GetTextChangesAsync method was originally added when
Document.GetTextChangesAsync was occasionally hanging.
Document.GetTextChangesAsync no longer hangs (in this codepath, at
least) but we still need to keep this method as a way of performing a
document text diff that falls back on using the
IDocumentTextDifferencingService (which in VS uses the editor's text
diffing algorithm) instead of falling back on diffing syntax trees
(which can produce diffs that are too large and disrupt certain
projection scenarios). This change updates the name of the method and
relocates it to below the method where it is consumed.

Attempting to generate a new file in an ASP.NET 5 web project would
deadlock because we were attempting to get the default namespace from a
worker thread.

The solution is to move the work of computing the default namespace from
ComputeOperationsAsync to GetOptions.  GetOptions is always guaranteed
to execute on the UI thread wheras ComputeOperationsAsync happens from a
worker thread.

This reverts commit 779cea70.

Attempting to generate a new file in an ASP.NET 5 web project would
deadlock because we were attempting to get the default namespace from a
worker thread.

The solution is to move the work of computing the default namespace from
ComputeOperationsAsync to GetOptions.  GetOptions is always guaranteed
to execute on the UI thread wheras ComputeOperationsAsync happens from a
worker thread.

Fixes bug #1053

Update CSharpRenameRewriterLanguageService.GetExpansionTarget to locate
good expansion target nodes for 1) expression-bodied members and 2)
lambdas that are not contained within a StatementSyntax and that have
ExpressionSyntax bodies. This allows all sub-expressions within these
nodes to be properly expanded & reduced during rename.

This removes the majority of references to the deprecated Desktop
assemblies.  The only remaining ones are in the VSIX projects.  They
must remain until we actually delete the assemblies.

for ExtensionManager.PerformFunction*()

Fixes internal TFS bug 1166482.

In cases where a fix provider throws an unhandled exception, ExtensionManager.PerformFunction*() was correctly handling the exception by displaying an 'info bar' alerting the user about the crash. However, because the defaultValue parameter for ExtensionManager.PerformFunction*() was optional, in some cases, we would end up returning default(ImmutableArray<T>) as opposed to ImmutableArray<T>.Empty to the VS platform's light bulb  engine. The difference is significant in this case since ImmutableArray<T> is a struct and since it is returned as an IEnumerable<T>. The platform code checks whether the returned IEnumerable<T> is 'null' (which it won't be) and then calls '.Any()' on it and this results in an InvalidOperationException from ImmutableArray<T>...

In addition to supplying the correct defaultValue of ImmutableArray<T>.Empty to avoid the above crash, I am also making defaultValue a required parameter (so that future consumers of ExtensionManager.PerformFunction*() don't run into this problem).

C# object creation preselection gets very confused in a situation like:

```
Task x = new $$
string x = "foo"
```
because the new keyword is actually a part of the second assignment
expression. It therefore selects string instead of Task. To avoid this,
the type inferrer now detects if new is on the left of a parenting
assignment expression and on the right of a grandparent assignment
expression.

Object creation preselection now uses the position-based mode of the
TypeInferrer, which needed to be tweaked to properly walk up from
ObjectCreationExpressions.

fixes internal issue #1107929

fixes internal issue #1107929