These can be very confusing, since other methods on Contract actually
throw exceptions. Since we have endless amounts of code directly calling
Debug.Assert, let's just use it everywhere.

VSTHRD103 reminds people not to use .Result in tasks, which is great
advice but we get a few false positives; in particular our
SafeContinueWith extension isn't understood by the analyzer that the
tasks involved are always completed, so you can just .Result them.
Rather than working around this, let's just disable the analyzer in
those cases.

* Add null check for textSnapshot

Fixes #7364

* Respond to feedback

Changed from return to continue and added a non fatal exception

* respond to feedback

Moved NullTextBufferException to InlineRenameSession and added SourceText.

All these uses weren't didn't need the IWpfTextView specialization,
so it's a simple swap.

Although this could be split out more precisely, for now we'll just
move the entire feature to the WPF layer. IEditorInlineRenameService.cs
is left behind however, as that interface is implemented by TypeScript
and other languages. For now I'm considering EditorFeatures.Wpf to be
an implementation assembly for now and so interfaces implemented
should still live in the base assembly.

In CSharpEditorFeatures and BasicEditorFeatures, there was the
implementation of IEditorInlineRenameService which had no language
specific details other than the language name the service was exported
for. I have moved those into EditorFeatures.Wpf rather than have
additional assemblies for language specific stuff, since I anticipate
that to be nearly non-existent.

also, now merged separate vs telemetry logger to one since telemetry activity is now obsolete. also remote host also now share logger since both is now on new API

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=227513

InlineRenameSession.ApplyReplacementText is called in response to buffer changes. In response to these changes, we want to (1) kick off some background work to calculate the new ConflictResolutionTask, (2) propagate the new replacementText to all buffers on the UI thread, and then (3) apply the results of the ConflictResolutionTask on the UI thread once they're ready.

Prior to this change, steps (1) and (3) were always done together, in sequence, regardless of how (2) was progressing. Since the replacementText propagation started synchronously and stayed on the UI thread, this usually meant that the application of the results of the ConflictResolutionTask would have to wait until the replacementText propagation completed (because it would wait for the UI thread to be available). This worked great, most of the time.

But, if the propagation of the replacementText causes a buffer change in a source controlled document and "Prompt for Checkout" is enabled, then a modal dialog to checkout files appears. Then, the UI thread pumps and allows more work to be scheduled there. Our ConflictResolutionTask could finish calculating conflicts and the application of these conflicts could be scheduled on the UI thread while a dialog is still up (and we are still propagating the replacementText). It would then try to manipulate the undo stack and apply edits to buffers. Since we still have an open undo transaction from the replacementText propagation,
the attempt to manipulate the undo stack would crash.

This change splits the kicking off of the ConflictResolutionTask and the application of the replacements it computes into separately callable methods that aren't automatically chained together. In some cases they can be called in sequence, emulating the old behavior. But when a text buffer edit triggers ApplyReplacementText, we first kick off the ConflictResolutionTask, then propagate the new replacementText, and *then*, once the replacementText is fully propagated (including the handling of any source control modal dialogs), we finally apply the results of the ConflictResolutionTask on the UI thread.

This does not guarantee that *no* reentrancy will ever happen in Inline Rename, but it gets rid of the biggest, obvious culprit. Completely safeguarding would require a larger change, and I think this approach
is the best one given our current RTM escrow timeline, and it will fix the problem for the vast majority of users encountering this problem.

Fixes #16460

Fixes #5076

- Introduce instructional text when the dashboard is first shown (or when newName = originalName). This should help users who are used to the pre-VS2015 modal dialog learn to edit the identifier inline in the editor. If we at some point add a way to launch Inline Rename with a new name already specified, we'll need to be a bit more careful about how to both show that new name *and* the instructional text.

- Show the newName as the user types it

- Rearranging the info in the window to flow a bit better:
    - Heading (rename from x to y, or show getting started instructions)
    - Settings
    - Summary (# locations to be updated and any conflict info).

- Slightly changed the reference count text from "found 1 reference in 1 file" (which made sense in large solutions where you saw "Searching..." for a while, which then got replaced with this text) to a more standalone version of "Rename will update 1 reference in 1 file."

That is, previous submissions.

Fixes #4923

Integration test(s) to follow.

Fell out of our normal cadence for this during the push for RTM. Now that we
had a bit more breathing room getting us back on track here.

Fixes internal bug #1176673

If a debug session enters run mode while an inline rename session is active, then we must abandon the rename session in its current state because we can neither commit the session (which may cause further changes) nor cancel the session (which will roll back to the original state). Allowing any of these edits through can at best prevent debugging data tips from working correctly, or at worst it can crash the process.

Ideally we would get notified that run mode is about to be entered while there's still time to adjust the sources, but that ability doesn't exist today.

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.

This change adds support for renaming methods that are referenced in nameof expressions during Inline Rename, Rename Tracking, and RenameSymbolAsync. For all of these features, there are three primary cases:

- Rename invoked from a method declaration with no overloads: Any nameof expressions that reference the method are unambiguous and are therefore updated to the new name.
- Rename invoked from a method declaration with overloads: In this case, any references in nameof expressions are renamed only if the RenameOverloads option is set to true (e.g. when the user checks the "Rename overloads" checkbox in Inline Rename).
- Rename invoked from a reference in a nameof expression: We always rename all overloads by automatically setting the RenameOverloads option to true and disabling Inline Rename's "Rename overloads" checkbox.