* fix mono set dirs

* fix path

* Delay actually loading the runtime to fix property setting
* Launch test for properties in separate process

.NET Framework domains

* Update CI actions
* Fix format

Co-authored-by: Mohamed Koubaa <koubaa@github.com>

* load the assembly and get function address inside the domain

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.

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.

* Add comment

* PR review feedback

---------

Co-authored-by: Mohamed Koubaa <koubaa@github.com>

…y. (#76)

#75

…_command_line (#66)

see https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md#initializing-host-context