Merge release/dev16.4 to release/dev16.5

Always return available for SyncClassView command

Fix classview sync

The changes made in https://github.com/dotnet/roslyn/pull/41123 fix the
GetHashCode for SubstitutedMethodSymbol for more nullability scenarios,
but end up hashing all generic methods with a non-generic containing
type into the same bucket. This can cause large performance regressions
for the compiler.

This change ensures that substituted symbols which have substitutions
equivalent to their original methods' type parameter continue to be
equal, but substituted methods with different type substitutions are not
considered equal.

Skip flaky Emit test

Part of https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1065328

Switch to UI thread before invoking Workspace.TryApplyChanges

LOC CHECKIN | dotnet/roslyn master | 20200204

Change to the VS release queue for integration tests

We recently changed this code to switch from using the Workspace Options setter (now deprecated) to Workspace.TryApplyChanges. This causes an intermittent exception [here](https://github.com/dotnet/roslyn/blob/aeb47891e92341b700c3a290a92553b8a91b445a/src/VisualStudio/Core/Def/Implementation/ProjectSystem/VisualStudioWorkspaceImpl.cs#L374-L377) when TryApplyChanges is invoked from a background thread.

Fixes internal Watson bug [#1062942](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1062942)

Delete the lazy caching of GetLatestProjectVersion()

Update arcade to support SDK publishing

See https://github.com/dotnet/arcade/issues/4759

Solution.GetLatestProjectVersion() returns the highest project version
of any of the Projects in the Solution. This is lazily computed, but
the lazy computation has a fatal flaw. It's implemented with a
Lazy<VersionStamp>, and if a Solution is changed and no project was
changed (say, you only modified a document's text), the existing
Lazy<VersionStamp> is reused. This causes us to root an older
SolutionState or ProjectState until somebody were to call
GetLatestProjectVersion() and cause the Lazy<VersionStamp> to be
evaluated.

Except...that would never happen. It turns out that nothing calls
GetLatestProjectVersion() in Visual Studio anywhere that I can find.
The only call is in one unit test that calls it and then ignores the
result. Thus, we'd simply leak the SolutionState/ProjectState until
some code ran that knew it could explicitly state the value instead of
reuse the existing Lazy<VersionStamp>.

Looking through history, it appears that this used to be used more
regularly as a part of an older implementation of the
ProjectDependencyGraph, but that was removed in
abd7654e.

Since nobody calls this, and the actual computation (just looping
through all projects to find the newest stamp) is fairly trivial, I'm
just going to delete all the lazy handling and just inline the
computation. In the unlikely case that this ever becomes a hot path,
we can revisit the laziness at that time.

Run naming styles on closed files

* MethodSymbol and FieldSymbol equality fixes:
 - Defer the equality of method/field symbol to the substituted symbol when compared
 - Make the hashcode of substituted method/field defer to the original definition

Preserve "unsafe" when refactoring between properties and methods

Allow -launch to be used without -build

Annotate implementations of IEventSymbol

Annotate implementations of ILabelSymbol

Rename from IncludeNonNullableReferenceTypeModifier to IncludeNotNullableReferenceTypeModifier (#41332)

* Set TEMP environment variable to $TempDir on CI machines

https://github.com/dotnet/arcade/pull/4744 reverted setting the variable in `tools.ps1` due to issues it caused in other repos.

Stop Simplifier.ReduceAsync removing empty arg lists from delegates

Fix for Visual Studio crashes when adding a parameter to a function

* Fix Pythia pooled objects wrappers

* Fix RPC

Fix issues in MetadataAsSource XML documentation comment conversion

Our best guess is we ran naming styles on open files only for two
reasons:

1. At the time, we only supported .editorconfig in-proc, so
   out of proc wouldn't have used the right settings.
2. Even if we were running in-proc, there might have been performance
   issues since we were running across a lot of files.

Neither of these concerns apply at this point: we now support
.editorconfig out of proc (both in the legacy path and the new path) and
since we're already running other analyzers that use .editorconfig,
the cost of processing it will exist regardless.

Make ValueText return empty instead of null

Target netcoreapp3.1