> I have attached a Python script which does what Antoine's patch does except
> which is expected to live in Tools/scripts. The perk of doing this in a
> Python script is that Windows users will be able to simply execute the script
> while the Makefile can be made to execute the script itself for those that
> prefer ``make test`` over ``./python Tools/scripts/run_tests.py``.

I've attached a patch that reworks the Makefile test targets to use this script
(with some minor modifications).

Some notes:
- By doing things this way, we lose the ability to specify custom arguments to
  the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
- The "test" and "quicktest" targets now use "-u all,-largefile,-audio,-gui",
  which permits more tests to be run. On my current system, this adds about 20s
  to the running time for "make test" (~3m45s instead of ~3m25s).
- regrtest.py now accepts "-u none", explicitly specifying the default setting
  (to override the setting used by run_tests.py). This isn't strictly necessary,
  but it seemed good to have, for the sake of completeness.
- I've changed the meaning of "-j 1" -- instead of using a single subprocess, it
  runs the tests directly in the current process. This allows us to use the
  run_tests.py script for "make buildbottest" and still have the exact same
  semantics (using even one subprocess can cause problems for e.g. test_curses).

Any thoughts?