When this test is not ignored, we get a crash.

The bug fixes are coming soon (there's three bugs).

Shut down python when the domain that loaded python reloads.

Also added comments explaining what the hashset is about.

1. Implement tp_traverse, tp_clear, and tp_is_gc in native code in memory that
   is *not* released upon domain reload.

   Effect: fixes the crash on domain reload.
   Side effect: leaks a page every domain reload.

2. Use python's platform package to determine what we're running on, so we can
   use the right mmap/mprotect or VirtualAlloc/VirtualProtect routines, the
   right flags for mmap, and (theoretically) the right native code.

   It should be easy to add another system, as long as it has the same kinds of
   functionality.

3. Enable the domain reload test. Added some unit tests for the new stuff.

4. Remove tp_traverse, tp_clear, and tp_is_gc where it was implemented.

Note: I haven't actually tested on windows and linux yet, I'm checking in so I
can do that easily.

Nothing major:
- python platform.machine() returns x86_64 on mac, and AMD64 on windows,
	for the same platform. Parse them properly.
- Microsoft's runtime C# compiler wants language version 2.0, so no
	$"{foo}" syntax in our debug printing.
- Microsoft has decided you can't catch SEGV even in a unit test, so
	disable that test on windows.

Most of my time was spent trying to convince VS to see the unit tests.

mac mmap allows it, so just set it on both platforms.

…nity-Technologies/pythonnet into uni-63112-hotreload-crash-test

…sh-test

Uni 63112 hotreload crash test

This test doesn't compile on appveyor and travis, because we use APIs from .NET
Framework 4.0 rather than .NET Standard. Even if it were fixed to compile, it
would throw exceptions because .NET Core doesn't have application domains.

Also disable the domain reload test under either NETSTANDARD or NETCOREAPP (the
former was used in the runtime, the latter in embed_tests).

When run with mono or in visual studio, DllImport("__Internal", ...) works; but
when run via dotnet, it fails to load the library somehow. mmap is in libc, so
get it that way now.

Exceptions thrown in NUnit setup/teardown get silently swallowed, so I also
added try/catch to dynamic.cs to help debug future initialization exceptions.

We can't check memory protections in an NUnit tests under Microsoft .NET
runtimes. I was assuming that meant windows only, but the travis CI pointed out
that it can mean linux as well.

The mess was caused by:
1. run a test that runs PythonEngine.Initialize() (probably implicitly)
2. run a test that does Runtime.Shutdown()
3. run a test that runs PythonEngine.Initialize() (probably implicitly)
Test number 3 ends up with an engine that's initialized but a runtime that's
shut down.

Somehow that was OK under python27.

Solution for now: don't shut down the runtime in tests.

I can't repro the error that appveyor is having on python34 at home.

Fixes a build break on travis. Seems the latest nuget is finding msbuild 15, whereas pythonnet.sln is for msbuild 14.

I'm hoping this will allow finding MSVC for python 3.4?

The sub-domain writelines were coming all at once, not interwoven as expected.

This seems to be the cause of an occasional TCP transport error on travis (we're writing to a closed pipe).

The previous attempt got further but got stuck trying to build psutil from source, with the infamous "error: INCLUDE environment variable is empty" error that means your windows setup won't be building wheels from source today.

This reverts commit f947e3b.

It didn't work because conda isn't apparently available.

Someone else can try to fix the problem that psutil is distributed as source, but appveyor won't build it.

Having the domains both writing to the console seems to have been causing trouble.