The ImportGroup element is just noise.  It was also used very inconsistently in the repo and often within the same project file.  Just remove it.

The dependency projects serve a few purposes:

- Help ensure package unity by serving as a single place for a NuGet reference.
- Make NuGet updates simple by having a single place to change.
- Grouping together related packages to make it easy to take a dependency on say Visual Studio editor.

The first two points are largely obsolete now that our project.json references are strictly validated on every build and have a single update mechanism.  This meant a lot of our depnedency projects were just making Roslyn.sln bigger.

As such I went through and deleted all of them which had only 1 or 2 project.json entries.  I left the VS ones which tend to group 10+ references together.  They are still serving a valid "reference VS" purpose.

Switch to using TaggedText (from SymbolDisplayPart) for features that want to display classified text.

* Merge pull request #12041 from heejaechang/buildsyncrace

found one more case where documentId can be null

* prevent VS from crashing if VS got shutdown while build error reporting is in progress.

* Update our NuGet package version to 1.3.2

* Update Microsoft.DiaSymReader.Native to 1.4.0 RTM (#12141)

* Enable building of release nuget packages.

This commit makes it so that we will always try to generate release nugets except if they depend on prerelease packages. If one of our nuget packages happens to depend on prerelease packages, then when building release nugets, we will simply print a message in the build output and skip release nuget generation for that package (and allow the overall build to succeed).

* Address code review feedback.

* Simplify script to use nuget.exe for prerelease dependency validation instead of adding custom logic in the script for this.

* Remove Microsoft.CodeAnalysis.EditorFeatures from list of prerelease nuget packages.

* Change the name of the error log file to skipped_packages.txt.

* fixed DifferenceViewer leak

this leak was responsible for about 14% of managed memory in customer's dump.

basically, in certain condition, if cancellation exception is thrown, we will not close difference viewer which cause
all text views to leak. that cause all taggers and text buffers to leak and that cause our preview workspaces to alive.
which in turn cause all solutions to alive and so on. all those objects (view, buffer, workspace, solution) are quite
big graphs. so ends up eat up 14% of memory.

added assert to make sure if we leak viewers again, we get some kind of notification.

this leak was responsible for about 14% of managed memory in customer's dump.

basically, in certain condition, if cancellation exception is thrown, we will not close difference viewer which cause
all text views to leak. that cause all taggers and text buffers to leak and that cause our preview workspaces to alive.
which in turn cause all solutions to alive and so on. all those objects (view, buffer, workspace, solution) are quite
big graphs. so ends up eat up 14% of memory.

added assert to make sure if we leak viewers again, we get some kind of notification.

It's contained in the diagnostics window VSIX, which we include in
the full deployment.