This is an automated migration of our project files to the new SDK /
PackageReference.  It is done using the tool located here:

https://github.com/jaredpar/ConvertPackageRef

While investigating #17570, I discovered that we would sometimes create
"deferred" Roslyn projects for .NET Core projects that just hadn't been
asynchronously created yet. In *theory* that did no functional harm - they would
just get closed and converted to real projects when the project system created
the real project, but might as well not even bother creating them.

While I'm here, clean up PR feedback from #17335.

We either don't use these, or pull them in from NuGet.

also, now merged separate vs telemetry logger to one since telemetry activity is now obsolete. also remote host also now share logger since both is now on new API

So, it turns out that when you AdviseSolutionEvents, the shell actually
checks the same object for all of the related solution events interfaces
to fire events to them. This meant that after commit
e6a43cb5, we never actually received any
IVsSolutionLoadEvents or IVsSolutionWorkingFoldersEvents. The impact of
this is that we never called "FinishLoad" to populate the Roslyn
workspace with the projects that had been loaded.

Most features would appear to work, as we would load a project and it's
dependencies when a file was opened, but we would then not load any
thing that depends on it, so features like Find All References and
Rename wouldn't work reliably.

Fixes
https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=389698.

In Lightweight solution load, we depend on
IVsSolutionEvents.OnAfterOpenSolution being called to populate the
workspace and create projects.  However we were subscribing from
VisualStudioProjectTracker, which we defer create until a project is
opened.  This meant we never got the event for the first time a solution
was opened, and so we failed to populate the workspace.

move down diagnostic analyzer executor down to workspace layer since all requires one now lives in workspace layer.

This changes our build so it will no longer consider the GAC when resolving assembly references.

Ensure that all *.*proj, *.props, and *.targets files are prefixed with the xml and copyright elements

This setting controls binary deployment hence it needs to be centrally
managed to help ensure we have a correct build.  Custom projects can
continue to control this setting themselves.

The dependency projects were added as a way to help unify our project.json references.  Instead of every project referencing the NuGet package, we had a dependency project which referenced it and everyone referenced that dependency project.  Due to the transitive nature of NuGet it would be roughly equivalent.

This system had a number of downsides:

1. There was no enforcement.  Even though dependency projects existed, there was no mechanism to force developers to use them.
2. Getting the granularity correct was tricky.
3. The projects themselves have special props / targets to get them to produce no output.  This can trip up MSBuild up to date checks.

Since then though we've begun using RepoUtil to verify our NuGet reference correctness.  This removed the need for these projects and hence I'm removing them from our build.

Previously, we'd raise workspace events on whatever synchronization
context created the workspace. If you created the VisualStudioWorkspace
on a background thread, then this would mean we'd raise events there
which is not expected by many parts of our codebase. This corrects that
ensuring they're always raised where they should be. This also applies
to all workspaces in Visual Studio, which has been a source of bugs
when somebody had another workspace that they created themselves
which broke expectations.

While doing this I simplifed the APIs to clarify what they were being
used for and also removed some FactoryFactories that were unnecessary.

Previously, when a VisualStudioWorkspace was constructed we were
doing a bunch of work in the constructor talking to the UI thread. This
was dangerous because we might get composed on a background thread.
This moves the dangerous initialization until we're creating a project
when we know we have a UI thread available.

In this refactoring I moved the project tracker and a few other fields
into a private class so it's more obvious what's dangerous to touch.
I also do a pass through all consumers of the property and either
update it to use the deferred state directly (because we're only
consuming projects, so it's fine if we don't have anything) or to the
factory method if we actually are creating projects.

This does temporarily regress the ability to create projects on
background threads, but it was unclear if that was generally safe to
start with.

Move the non-Roslyn document listener hookup until the document is initialized and track text buffer changes instead of forcing the WpfTextView

This should fix the Open file RPS regression in VSO #[223317](https://devdiv.visualstudio.com/DevDiv/_workitems?_a=edit&id=223317&triage=true)

These used to be split up into separate assemblies, but aren't anymore.