Projects should not end up with reference to adapter DLL

[idg10]

Adding the adapter as a NuGet package shouldn't cause the library to appear in the project's list of references.

So instead of putting our DLLs in the lib\net45 folder, they should go in a tools folder. That way, VS will copy them to the LOCALAPPDATA\Temp\VisualStudioTestExplorerExtensions\ folder but won't add them to the project.

Unfortunately, this adds considerable complication because it essentially makes it impossible to share types across AppDomain boundaries. If our adapter is in the test project, this just works, because we can use normal name-based assembly resolution, which resolves the assembly as having the same identity in all AppDomains. We have to move to providing a path to the assembly when instantiating types in the temporary appdomain, which seems to partially break this. (We need to load the test project DLL into an AppDomain so that we can unload it once we're done. Otherwise, you end up locking files.)

The weird thing is that we can still instantiate a custom type across the AppDomain boundary, but it breaks if we attempt to pass it any constructor arguments which are also of a custom type.

This means we end up needing to ensure that the only things we pass across the AppDomain boundary as constructor arguments are types already known to the .NET Framework.