Add some more AnalyzerConfigDocument functionality to the VisualStudio layer. This includes the changes to enable Preview workspace and Preview changes functionality for analyzer config documents

This renames Create to TryCreate.

We never actually had any tests that tested Code Model and our project
system shims at the same time. To fix this required pulling
RoslynVisualStudioWorkspace.GetFileCodeModel down to
VisualStudioWorkspaceImpl, and fixing up some mocks we have to be
(every so) slightly more accurate.

Just removing a TODO.

The implementation was commented out and not restored prior to merging
the project system refactoring.

TypeScript uses the AbstractProject and VisualStudioProjectTracker to
add and remove projects; this adds back a minimal shim for them to use.

This produces a new free-threaded, well factored API for adding projects
to the VisualStudioWorkspace. The core type is the VisualStudioProject
which is a free-threaded API that you can use to push information over.
CSharpProjectShim, VisualBasicProject and CPSProject each have an
instance of VisualStudioProject that they push things through.

The inheritence model here is now smaller. CSharpProjectShim and
VisualBasicProject inherit from AbstractLegacyProject, but that's it.
CPSProject now inherits nothing, and AbstractProject is here purely
for TypeScript back-compat until they're moved onto the new APIs. The
expectation is F# and TypeScript both move to VisualStudioProject, which
we make public in some form. Then that type will go away.

VisualStudioWorkspace had a virtual method to send a call over to
the code model logic. Since we now have the requisite interface callable
directly, we should just call it directly. It also saves us the trouble
of passing a DocumentId only to re-decompose the type again.

Our CodeModel implementation would go to AbstractProjects and then
see if the implemented a special interface IProjectCodeModelProvider
to fetch their ProjectCodeModel. This abstraction was pretty leaky:
since we're already assuming carnal knowledge of AbstractProject,
we can just make it a property that might be null and be done with it.
This means we can push some code that is in very derived types (and
duplicated) down into a single shared type.

At this point, all project system calls flow through IProjectCodeModel,
and the only tangling back to AbstractProject is just to do the lookup
from project -> IProjectCodeModel. We can now introduce an interface
IProjectCodeModelFactory that just maintains that mapping and then
suddenly things are really clean.

This interface is able to live in our ServicesVisualStudio project
and that's what the project systems are able to interact with. This
makes the API more like an "optional service" that they can create.
Down the road, we can just have an IProjectCodeModelFactory that
keeps the implementation entirely separated out.

Rather than using inheritence, we only need one factory method. By
favoring composition here this will set us up to remove a bunch
of derived types.

This commit is admittedly strange, as in some cases we now have a
child type being created in derived types of AbstractProjectCodeModel.
This is just to move things around, and it'll get better in the next
commit.

This was being used directly in a lot of places, but I think it's a bit
eaiser to follow object relationships if all creation methods go
through AbstractProjectCodeModel, and from there might get forwarded.

A fair number of checks were being made of whether the CodeModelCache
was null; I don't believe these make sense. Once the underlying
_codeModelCache type is made non-null, it is never set to null, and the
only way it could fail to create in the first place is if the project
was never in the ProjectTracker. Given we only produce these once we
already have a live AbstractProject, that's not possible.

Move helper API up as it will be using functionality in EditorFeatures as part of FAR refactoring work.

Rename intenral code to 'FindUsages' so it better reflects that it can present results for more than just FindReferences.

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.

This introduces a new core interface IDocumentOptionsProvider that
lets you provide options for documents. There's a factory to create them
to deal with the fact the implementation will be living in
EditorFeatures.Next.csproj for now.