We had a cache in AnalyzerAssemblyLoader that tried to cache and reuse
the same assembly, keyed by assembly identity. This code makes some
sense to keep around for the .NET full framework case where we can't
load multiple assemblies with the same identity, but doesn't make
sense to keep around for our AssemblyLoadContext implementation.
The AssemblyLoadContext code correctly isolated dependencies and didn't
use this cache when resolving dependencies, but it was still active when
the public LoadFromPath entrypoint was called -- we'd hit the cache
there before doing anything else.

To ensure we don't have any identity-related caching logic reappearing
in the AssemblyLoadContext implementation, the identity-related logic
has been moved to DefaultAnalyzerAssemblyLoader.Desktop.cs, which
greatly simplifies the base type.

If you had loading happening at the same time as a call to
AddDependencyLocation, bad things might happen:

- GetPaths wasn't taking a lock before looking at the dictionary
- Code used the returned HashSet outside of the guarding lock

When we're loading analyzer dependencies, our current logic was to
require the exact version that was requested from the loading
assembly. This is problematic in a lot of cases where you would normally
have a binding redirect to ensure assemblies load cleanly in diamond
dependency scenarios. Without this, if you depend on B.dll and A.dll,
but B.dll depends on an older version of A.dll, you can't produce a
package that actually loads because there's no sane way to package both
A.dlls at the same time.

We avoid adding any logic here where we'll still try to use an older
version if that's still available. Consider a more complicated example
of:

1. Analyzer 1 depends on and ships B.dll (version 2) and A.dll
   (version 2); B.dll (version 2) depends on A.dll (version 1).
2. Analyzer 2 depends on A.dll (version 1) and ships that.

When loading Analyzer 1, we need a redirect to ensure the A that it
consumes and the A that B consumes are unified. We don't want the
presence of Analyzer 2 to change that. We could satisfy B.dll's request
with Ananlyer 2's dependency, but if Analyzer 1 expects type unification
then adding Analyzer 2 to the build would break it.

Fixes dotnet#53672