* make diagnostic analyzer service lazy and not require UI thread.

require ExtensionManager change that got checked into 15.8

* change location where we log number of workspace analyzer references due to it being lazy now.

* PR feedback

These tests were all using WpfFact, but not actually doing anything
that required either WPF or an STA thread. We plan to enable
parallelization of Facts (but not WpfFacts), and this ensures we can
parallelize as many tests as possible.

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