We pick up these references from EditorFeatures.csproj, so no reason
to restate.

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.

Moving up to EditorFeatures.Wpf for now. It could potentially go higher
if we determine this is a Visual Studio-only thing, but for now it's
unclear where it will ultimately land.

Fixes dotnet/roslyn#23184.

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.

It already had access to EditorFeatures non-WPF, and so this isn't
granting access to anything it didn't already have access to.

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.

This removes WPF and XML references.

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 uses WPF clipboard operations to allow us to save fancy
interactive command history to the clipboard.

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

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.

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

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.

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.

This is a (currently empty) project that will contain parts of
EditorFeatures that demand the WPF surface area.