Create new project for common types that need to target net472

[davidwengier]

Fixes the build break in https://github.com/xamarin/vsmac/pull/3092

Reviewing commit-by-commit should be pretty straight forward, but all at once might be fine too if GitHub displays things nicely. There are no code changes, only project file changes (etc) and file moves.

The story so far:

• In order to target MS.CA.EditorFeatures to netstandard2.0 a PR was created (Refactoring to target EditorFeature to netstandard2 #46983) that moved a bunch of types to MS.CA.EditorFeatures.Wpf, because there is an editor dependency that is net472.
• This broke VS for Mac's SignatureHelp code, so I linked some of the files from MS.CA.EditorFeatures.Wpf into MS.CA.EditorFeatures.Cocoa so that VS for Mac could still compile (Bring SignatureHelp support from EditorFeatures.Wpf to EditorFeatures.Cocoa #50389)
• TypeScript responded to the change in the first PR, by adding a reference to MS.CA.EditorFeatures.Wpf but this breaks their insertion into VS for Mac (https://github.com/xamarin/vsmac/pull/3092), because their library is shared between Windows and Mac

The solution:

• Seems to me we need a new library that can target net472, but not be platform specific like the Wpf and Cocoa libraries are
• I have chosen Microsoft.CodeAnalysis.EditorFeatures.DesktopCommon for this new library, but open to bikeshedding (its a little wordy)
• As usual this stuff happens on a Friday afternoon (for me) so I'm preparing a PR before discussing because timezones
• I have no idea what I need to do for a new DLL (RPS exception??) so advice is appreciated (I saw an OptProf file but it scared me)

FYI @genlu @KirillOsenkov @uniqueiniquity

[jasonmalinowski]

@davidwengier What was the answer from the editor team why we can't just fix the reference on their side? If the workarounds are getting more complicated it seems like we really just need to fix that.

[davidwengier]

What was the answer from the editor team why we can't just fix the reference on their side?

@genlu I think you were following that up? I didn't I'm afraid.

If the workarounds are getting more complicated it seems like we really just need to fix that.

I think the previous PRs were workarounds, but to me this isn't. As I see it this is probably what should have happened with the stuff in MS.CA.EF originally, for it to go to netstandard, but nobody remembers that VS Mac exists. If we need to have a net472 library, and given that currently both Visual Studio and Visual Studio for Mac build for that target framework, that seems reasonable/likely to me, then having a platform-agnostic library that targets it makes sense to me.

I think there also might be future possibilities to move some code around and trim EF.Wpf and EF.Cocoa to the most minimal they can be, and have more shared code in this.

[sharwell]

From the description, it sounds like the Roslyn change remains correct and no additional layer is desired or needed. It looks like the problem is in these two steps:

This broke VS for Mac's SignatureHelp code, so I linked some of the files from MS.CA.EditorFeatures.Wpf into MS.CA.EditorFeatures.Cocoa so that VS for Mac could still compile

EditorFeatures.Cocoa references Microsoft.VisualStudio.Language.IntelliSense. This is a WPF dependency that needs to be eliminated from this layer. There are no plans to make this package work in Mono.

TypeScript responded to the change in the first PR, by adding a reference to MS.CA.EditorFeatures.Wpf

This is not allowed for code that needs to run on Mono. The reference needs to be removed, or the assembly needs to be restricted to execution only in VS.

... common types that need to target net472 ...

EditorFeatures.Wpf has common types with WPF dependencies. EditorFeatures has common types without WPF dependencies.

[davidwengier]

Replaced by #50709