Make ParallelContext work on Windows.
Call some Win32 API via ctypes so that we can wait on child processes.
We still use subprocess, but call OpenProcess() to get a process HANDLE
from a PID, and maintain a global dict of HANDLE -> PID. Then, to emulate
os.waitpid(-1), we call WaitForMultipleObjects() on the list of open
HANDLES. See the code sample I wrote for this here:
http://stackoverflow.com/questions/100624/python-on-windows-how-to-wait-for-multiple-child-processes/573196#573196

Some more win32-compat changes
* Add a 'returncode-on' setting to the test harness so we can fail tests per-platform.
* Split the symlink tests out of file-functions.mk into file-functions-symlinks.mk, and fail that on Windows.
* Use forward slashes consistently in filenames to be compatible with GNU Make on Windows.
* Fix PatternRule to execute through the MSYS shell when running under MSYS.
* Change automatic-variables.mk to not use 'mkdir -p src/subdir subd' as that breaks due to a MSYS mkdir bug.
* Change include-notfound.mk, since MAKEFILE_LIST uses native win32 paths on GNU Make on Windows (even in MSYS)
* Add a NATIVE_TESTPATH variable to the test harness.
* Pass a __WIN32__ variable from the test harness when running on Win32.

Correctly implement separate MAKEFLAGS and actual command line handling so the command line overrides the MAKEFLAGS. optparse is weird

b22e68988ccc: Much better context management: we can assert that everything is done within a context as we "finish" it, and we can use multiple contexts without having to wait on each one sequentially. I need to write some more tests, but this has me feeling pretty good.
parallel-execution

Much better context management: we can assert that everything is done within a context as we "finish" it, and we can use multiple contexts without having to wait on each one sequentially. I need to write some more tests, but this has me feeling pretty good.

1d0ad43d2ff7: Pass -j options down, and then ignore them in submakes unless they are -j1... this isn't quite right, but is closer.
parallel-execution

7e3690d47d4d: Initial implementation of parallel execution. This passes the testsuite, but has some issues. In particular, hitting Ctrl-C during execution tends to not kill everything in a process chain and leaves submakes as running orphans.
parallel-execution

Initial implementation of parallel execution. This passes the testsuite, but has some issues. In particular, hitting Ctrl-C during execution tends to not kill everything in a process chain and leaves submakes as running orphans.
I chose threads for process.py primarily because there wasn't a simple way to wait for multiple processes in Windows. I think it's probably a bad choice and I'm going to go back to single-threaded using os.waitpid and some hacky Windows equivalent.

9c0fa7855fb0: Rename remake() (which looks like a public method) to _beingremade() which is clearly private.