Fix VB incorrectly reported redundant casts in compound assignment statements

Consider the following code:

```VB
Dim b As Byte
b += CByte(1)
```

The `CByte` cast can be removed if the Option Strict is Off. However, if Option Strict is On, the compiler
produces an error ("Option Strict On disallows implicit conversions from 'Integer' to 'Byte'").

The issue here is that compound statements are not considered by unnecessary cast detection. Unfortunately,
supporting is not as straight forward as I'd hoped for a couple of reasons:

1. There is no compiler API to get the built-in operator used by a VB assignment statement. If there were, this
would be a straightforward fix since removing the cast results in the compiler choosing `System.Int32.op_Add(Int32, Int32)`
rather than `System.Byte.op_Add(Byte, Byte)`.

2. There is a hidden narrowing-numeric conversion of a constant value in the following code:

```VB
b += 1
```

Using the compiler API to classify conversion from the expression `1` to the type of `b` results in a
widening-numeric conversion, which is misleading since the type of `1` is `System.Int32` and the type of `b`
is `System.Byte`.

Fixing the problem requires two changes:

1. Actually support assignment statements in the speculative analyzer and check to see if replacment would break
the compound assignment.
2. Add a special case in the VB speculative analyzer in the case that Option Strict is not Off and the expression
has a constant value. In that case, we use a different compiler API to classify *the type of the expression* `1` to
the type of `b`, rather than classifying *the expression* `1` to the type of `b`.

Properly handle VB WithEvents fields in metadata code model elements

Remove equivalenceKey from CodeAction.Create overload

Actually delete PumpingWait

Log low VM telemetry at most once per session

Fix VB Spellchecker Crash
Fixes #6338

Now that the internal dependencies have been removed we can delete the PumpingWait methods.

Support for ISymUnmanagedWriter7 deterministic PDB ID setting

Avoid depencency on the exact order of AssemblyRefs in tests

Add logging to find all reference command handler

Automatically calculate equivalence keys from nested actions.

Fixes #5975.

Disable BackgroundCompiler on low VM

[AskMode] Rename MS.CA.Scripting.CSharp to MS.CA.CSharp.Scripting...

[AskMode] Allow return statements in scripts...

Fix VSIX based analyzers installed in the extensions hive

Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work.

Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path.

Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers.

Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change.

Fixes #6285 

...and update namespaces contained therein accordingly.

* Remove lots of duplicated code
* Add support for testing external code elements

Remove PumpingWait

This removes PumpingWait from our test infrastructure and replaces it with proper await calls on the Task(s) in question.

Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work.

Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path.

Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers.

Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change.

Fixes #6285

Add a PE file section for determinism

Fixes for Building with Update 1

Properly map snapshot points up when testing if adornments should be visible or not.

Fixes #5969