- increase the time limit here
- Have the tester print out the stderr when a test fails with the wrong exit code;
  this might make things spammy but I hope that it will be more helpful.
- Base EXTMODULE_DIR_PYSTON off the executable, not the tester
- modifying os.environ has no effect, even when spawning subprocesses...

Until I can figure out what the issue is that's making them fail.
(I don't feel great about removing tests, but I just added these a
few commits ago, so I think this makes the most sense for now.)

- generalize dynamic loading support
- copy include files to cmake build directory: we don't need it for our build,
  but we need them to be there for building extension modules
- some beginning hacks for supporting Cython

(increase the reopt and osr thresholds by 2x)

This helps django a ton.  will probably hurt our microbenchmarks
but I don't care much about those right now.

The issue is a difference between how PhiAnalysis and TypeAnalysis
handle OSR compilations: type analysis is osr-aware but phi analysis
isn't.  I think the right solution to this is to make phi and
definedness analysis also osr aware, but I want to get these other changes
in.

Set correct site-package directory, fix 'str * -1', add sys.dont_write_bytecode

Attach BoxedFile::gcHandler.

cmake explicitly list all c++ source files

Beginnings of a testsuite, starting with a simple django test.
Increases testing time by about 45 seconds which isn't great, but
tests a lot of stuff which is good.

We don't support arbitrary dict-like objects as the globals, but
in the special case that that dict-like object is just an attrwrapper
around the current module, we can fall back on our module-as-globals
support.

(Django 1.7.5)

We had a few callers but they weren't actually using the fact
that the strings were interned.

Implement misc stuff

This both lets us reuse the frame object and verify
that the BoxedFrame is still valid.

Conflicts:
	src/codegen/unwinding.cpp
	src/codegen/unwinding.h

The first change is to move to a PIMPL strategy so that
we can provide a more extensive unwinding API to other modules.
In particular, you can get access to a python frame iterator
and make repeated calls on it.  This is in preparation of the
sys._getframe implementation.

This also exposed an issue with our usage of libunwind -- basically
you have to do all of your unwinding in one function, but we were
doing it in several different functions and happening to get away
with it.  So, switch from a C++11 range-for loop which is nicer, to
a callback approach which is less nice in my opinion, but safer.