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.

Thankfully the only things still using the old glyph types (versus
the new image monikers) are already in the Visual Studio layer, so
this is an easy move.

No reason to have trivial extension methods used in one place.

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.

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.

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 wasn't included in the project file, so clearly wasn't being used.

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

* Adding cobyrc file for testing

* Adding isImplicit info to ioperation tests

* Adding Language name to the test dumper

* Formatting change to test dumper

* Removing cobyrc file

* Fixing more tests

* Resolving conflicts

* Moving the language to assert check

* Resolving conflicts

* Reacting to merge conflict

Fixes #21768
Fixes #22027

Reduce DocumentId array allocations

Since ImmutableDictionary and ImmutableSortedDictionary are both
implemented via trees; you can think of an ImmutableDictionary as just
being a sorted dictionary where the underlying key is the hash int.
Since our hash is just a hash of a GUID, we can compare by the GUID,
switch to a ImmutableSortedDictionary, and then avoid another sort
when we're computing checksums.

Bump NuGet monikers for the preview 1 split

There is no conversion between ref like types and either object or generic parameters (even if constrained to struct) in either direction. This change enforces that rule and adds tests around pattern matching, which exercises this rule.

We previously were using ImmutableArrays, so if you had a large number
of documents (say thousands) we'd be creating huge numbers of huge
arrays over and over again. For this pattern, ImmutableList is more
appropriate.

Fix bug in build-utils Ensure-SdkInPathAndData

Add unit tests for omitted arguments

Add unit tests for IArrayElementReferenceExpression and make the API …

Most constructs already had tests, but I added a few more just in case.
Although Span return in iterators is currently impossible because no
ref-struct capable type can be an iterator, I added a safety check in
case we allow it later.

Fixes #22305

Temporarily moves checks for `partial` back into the parser.

Fixes #22379

Fixes #18348