This change disables AppDomain isolation in the unit tests that don't require it.  This is necessary for our goal of running many of the suites on CoreCLR and helps reduce our exposure to #6358.

The AppDomain creation code incorrectly used AppDomain.CurrentDomain.BaseDirectory as the new base directory.  There is no gurantee this points to the directory containing the unit test binaries and this is actually the case in xunit without AppDomains.  Instead it points to the directory containing xunit.oconsole.x86 and uses AppDomain.ResolveAssembly / LoadFrom to resolve unit test binaries.

Switching over to no AppDomains in xunit was causing the creation of RuntimeAssemblyManager across AppDomains to fail.  The error given was a failure to load Roslyn.Test.Utilities.Desktop in the original AppDomain.  This is odd given that the code is executing inside Roslyn.Test.Utilities.Desktop.  The error was fixed by hooking AppDomain.AssemblyResolve in the original AppDomain and essentially reloading the DLL.  I'm not completely sure why this worked but I suspect it has to do with the original AppDomain having an incorrect base directory.

since this logic is now exposed to outside of engine, engine needs to be guarded from abuser so, logic is added to drop cache if there is too many high priority work. before only engine can decide what is high priority or not.

* Remove unintentionally added extra option.
* Rename NavInfo property to NavInfoFactory.
* Add fallback to metadata-as-source if NavInfo can't be retrieved for some reason.
* Use [ExportLanguageService] attributes rather than language service factories.
* Add NavInfo tests for generic methods and types
* Add negative NavInfo tests for parameters, locals and labels
* Rename UsePreviewTab option to PreferProvisionalTab to remove some confusion around what it does, and document it.

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

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

These interfaces change between VS versions, so this makes us not
dependent upon a specific version of VS.

We don't need SolutionDir or RestorePackages, which were for very old-
style restore systems.

With Visual Studio 2015 Update 1 you should not specify -anycpu
in the runtimes section. Right now we'll have both to allow us to build
with and without Update 1, and we'll remove the old ones once we've
made the transition.

Update 1 also tries deploying implementations for some class libraries,
so I'm updating all our test and VSIX deployment class libraries to
now include implementations.