Support pythonnet for AppDomain

[koubaa]

Related to pythonnet/pythonnet#2053
Fixes #53

When using domain.Load for an assembly, the assembly resolution rules are awkward Even if the full path is given to the AssemblyName, when the domain tries to load the assembly, it does not use that context and tries to resolve the assembly using normal domain resolution rules, which would require an assembly resolver to be installed. However, the assembly resolver that is actually used at runtime is the one installed to the main appdomain.

This prevents a library like Python.Runtime.dll (used by pythonnet) which is not installed to the application base directory to be loaded by clr_loader.

It is possible for an assembly to run code in another appdomain (using DoCallBack), but only if that assembly is reachable from the BaseDirectory. ClrLoader was not reachable because the base directory was hardcoded to that which contained python.exe, and ClrLoader.dll is not found there. I fixed this by making the folder which contains ClrLoader.dll the BaseDirectory for app domains created by ClrLoader.

To fix this issue, the assembly resolver of the main appdomain is lazily extending to include paths needed for libraries passed into GetFunction, and GetFunction internally uses AppDomain.DoCallBack() to marshal the function pointer inside the target app domain, using global domain data to access the function pointer and return it to the user of clr_loader.

With these changes, the following block:

import clr_loader
netfx = clr_loader.get_netfx(domain="Python", config_file=config_file)
from pythonnet import load
load(netfx)
import System
print(System.AppDomain.CurrentDomain.FriendlyName)

will print "Python"

[filmor]

Very nice, thank you! I'll fix the CI on master s.t. you can rebase on that.

[koubaa]

@filmor I don't have permission to merge this. I updated the code to resolve all of your feedback.