* Introduce LanguageVersion.CSharp9
* Limit netcoreapp3.0, 3.1 and netstdard 2.1 to C# 8.0
* Map CSharp9 to language version preview
* Default to CSharp9 for netcoreapp5.0
* Add Tests

Include line numbers in Integration Test stack traces

Fix failure to reuse pooled connections

Updates the option page type GUID to match the one in pkgdef

Track unrooted symbols in HashSet instead of ConditionalWeakTable

Microsoft.Net.Compilers.Toolset
 From Version 3.7.0-4.20314.5 -> To Version 3.7.0-4.20319.6
Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Fix descriptions for XMLDoc Triple Apostrophes in some languages.

Records need to provide a new form of source property symbol with
different syntax. This PR extracts a new base class to try to share as
much code as possible with the existing SourcePropertySymbol and the
SynthesizedRecordPropertySymbol.

Remove unnecessary conditional compilation

Refactor IDE open file diagnostic analysis + some perf improvements

Move SourceOrdinaryMethodSymbol functionality that is not syntax specific into a new base class. (#45424)

This work is related to #45296.

Don't fetch output paths for Intellisense projects

Document and test how CanApplyParse/CompilationOptions works

Closes #32732

Fixes #375

Add new public APIs to CompilationWithAnalyzers to fetch syntax and s…

Fix for incorrect IDE0007 implicit type diagnostic being reported in switch expressions

Bug 11510

Remove the OperationConstantValue wrapper type and push the WeakReference logic into string specialized ConstantValue implemention. Optimized internal calls to `ConstantValue.HasValue` to get the underlying instance to avoid realizing strings for these cases.

Web projects based on the legacy project system use special projects
called "intellisense projects" which are fake projects that are used
to act as a container for some contained languages. These are usually
created with the same IVsHierarchy as a regular project, which has an
unfortunate side effect. We get our build output paths from the
IVsHierarchy, so it would mean both the "real" project and the
Intellisense project would get the same output path.

In VS 2017, we would use that build output path to potentially convert
metadata references on disk back to project references. The ambiguous
path was problematic, but there was a bug: if the metadata reference
was converted to a project reference when there was only one project
(i.e. before you opened the file with a contained document), we
converted it but then left that project converted; if a later project
came along and outputted to the same output path the connection would
be left around. If the reference got added after the duplicate project,
it'd potentially stay a metadata reference.

In VS 2019, we rewrote the whole system that did
metadata-reference-to-project-reference conversion, and this time wrote
it "correctly" in that the end state didn't depend on the order of
events you took to get there; if you have two projects outputting the
same path, then we just don't convert a metadata reference to a project
reference.

The fix being taken here is to recognize when the projects we are being
handed are IVsIntellisenseProjects which means we can distinguish the
projects that don't need an output path from ones that do. This ensures
we don't end up with these projects having output paths at all, which
probably wouldn't end well since they don't correspond to the actual
code ultimately emitted to disk. We'll only ignore the project if
it also has a duplicate IVsHierarchy, to avoid breaking project types
(like database projects) that do create an IVsIntellisenseProject for
some files, but it's not a secondary project but rather the only
project.