The QuickInfoDisplayDeferredContent type was somewhat evil: it had a
set of properties that were intended as test-only accessors, that would
give you access to fields of type IDeferredQuickInfoContent but would
cast to the expected concrete type. In a previous refactoring I
started using those properties in the product which breaks F# because it may
create different implementations from IDeferredQuickInfoContent.

My fix here is just to delete the properties and clean up the test
helpers to do explicit casting. By refactoring the helpers a bit the
test complexity doesn't change and eliminates the trap in the first
place.

This takes care of Microsoft.VisualStudio.Imaging and
Microsoft.VisualStudio.ImageCatalog, which for now aren't available
outside Visual Studio. ImageCatalog is a pretty simple data API so
one day it might be useful, but for now isn't.

Fixes dotnet/roslyn#23189.

This depends on VS APIs that we don't have open source yet, and we
don't need the feature for now in VS for Mac.

Fixes dotnet/roslyn#23192.

The trim_trailing_whitespace can affect tokens to the right of the caret
so we need to check the token to the left.

* added time tracking to completion set.

from the point we start completion set to first time we are called from VS for best match (which indicate that completion set is actually shown to users first time for this particular completion session)

the event is vs/ide/vbcs/intellisense/completion

if completion is done without showing UI to users (etc or tab), then event will be marked as cancelled.

* added perf tracking to LB fix all.

there were already existing events so I just made those to include perf info (duration) as well.

among all those events, these 2 are ones we were planning to add

vs/ide/vbcs/codefixes/fixalloccurrencescomputation
this shows time from the point user invoked fix all to where we shows preview window to users.

vs/ide/vbcs/codefixes/applychanges
this shows time from user clicked Apply from preview window to where we actually applied the changes to VS

there are more events between them in case we want to dig in details later such as how long it took to calculate diagnostics, how many files are affected and etc.

also all related events have correlation id to group related code fix events. also for fix all case, it contains scope to show whether fix all is for document, project, solution.

* PR feedback. removed unnecessary parameter

* removed repeated correction id set

* updated comments.

Call Hierarchy items hold onto their project so we can relocate the
symbol, but instead of using the project that contained the caller, we
were creating items with the project of the original method. This meant
that further expansions wouldn't work correctly.

Before this, if we couldn't find the project we'd throw exceptions
and possibly crash or do something bad.

Holding onto Project directly meant the snapshot would be leaked. We
should only hold onto the SymbolKey so we can resolve it later.

If a symbol couldn't be resolved, we would bail the search and never
notify the UI that we stopped searching. We also wouldn't complete
the IAsyncToken either.

While I was here I also noticed that we were starting the async
operation asynchronously which could have resulted in flakiness in
integration tests. Our pattern is anything starting async work should
start the operation right away, so we can confidently wait until the
operation is complete.

# Conflicts:
#	src/EditorFeatures/Core/Implementation/CallHierarchy/Finders/AbstractCallFinder.cs

Given this is just converting from one string to another we can leave
this down in the EditorFeatures layer, and not in the Presentation
folder where it never should have been in the first place.

ClassificationFormatDefinition are only defined in
Microsoft.VisualStudio.Text.UI.Wpf.

This is the service which maps to WPF elements, or colors which
therefore isn't available once we remove our dependency on
Microsoft.VisualStudio.Text.UI.Wpf.

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

Right now some of this depends on our ability to make text views
when we hover over things, so for now we'll leave it up here. This
is a fairly weak dependency and will be able to move back soon.

This is a really ugly refactoring that removes the WPF APIs from
IDeferredQuickInfoContent and adds a service in EditorFeatures.Wpf that
converts from them to WPF elements. It's a straightforward refactoring
and everything still works, but it's not pretty at all.

EventHookup also worked with QuickInfo directly, and thus had to be
moved out of CSharpEditorFeatures. There isn't a CSharp-specific
EditorFeatures.Wpf assembly, so it's going into the Visual Studio layer
for now.

This is our abstraction for showing dialogs, so the WPF implementation
needs to depend on WPF.

The editor provides an API if it's in high contrast mode which can
happen either because the system is in high contrast mode or they've
chosen a Visual Studio theme that is higher contrast. This eliminates
an icky WPF dependency.

We stil disable generation of the classification if we are in this
mode, because editor ignores the tags we'd produce anyways when in
contrast mode.

Our presenter depends on the VS completion APIs (which aren't currently
implemented in a cross-platform way) and also depends on creating WPF
elements for tooltips, which means it can't live in EditorFeatures.Wpf
for now.

This should have been deleted in my merging of EditorFeatures.Next
but I missed it.

These speak in terms of WPF colors and brushes, so must be moved out.

Given this depends on various VS APIs and low demand for it to work
in other hosts, we can just move it here for now.

Unfortunately the tagger exposes "LineSeparatorTag" which itself exposes
WPF elements for how the tagging should be done. If it wasn't for this
mix we could have kept the tagger as a data layer in EditorFeatures
but that's not going to work.

This lets us remove a dependency in EditorFeatures.csproj on
System.Drawing.