VS: Use IViewElementFactory as intended

[majocha]

Alternative approach to styling QuickInfo, to address the issue with our IViewElementFactory being picked up by other packages in VS.
Now we provide content using the cross platform objects (ClassifiedTextElement at al.) and let VS render them. Custom visuals are provided by our internal FSharpStyle so the type conversion should never be available to other VS inhabitants.
To make the links look nicer we imperatively touch up the visual tree created by VS. Maybe not a standard, but still a legit way to do this.

FSharpStyle overrides ToString to render paragraphs and separators cross platform. (To see this in action in VS on Windows just comment out [<Export(typeof<IViewElementFactory>)>])

[T-Gro]

Thanks for the quick turnaround @majocha .

Since the original regression happened as a perf regression for CPlusPlus coding tooltips, could we test that it isn't happening again? As in F# MEF-registered service is not being loaded in non-F# context.

[majocha]

Since the original regression happened as a perf regression for CPlusPlus coding tooltips, could we test that it isn't happening again? As in F# MEF-registered service is not being loaded in non-F# context.

Probably we could, the starting point would be to obtain IViewElementFactoryService and create a few standard elements. The next step would be to check if MEF loaded anything from FSharp.Editor. I'm not sure how to do it.

[vzarytovskii]

I have re-targeted it to 17.7, so we don't wait for bot to merge it.

[majocha]

Does it need to be merged into main also?

[vzarytovskii]

Does it need to be merged into main also?

Not necessary, I usually don't bother with such changes. It will get there once 17.7 is merged back, but if you'd like to, you can cherry pick and PR it

[vzarytovskii]

/backport to main

[github-actions]

Started backporting to main: https://github.com/dotnet/fsharp/actions/runs/4925202806

[vzarytovskii]

Reason for backporting - I want it in main and my branch, where I publish custom VSIX