Take a pass over the CPython tests

and only run the small variant in debug mode to avoid timeouts.
Previously I had tried splitting it in half, but it looks like that's
both not enough to avoid timeouts, and it also has a race condition when
trying to run two copies of the test at the same time (one will read the
not-fully-written pickled output of the other).

Two of these tests pass in release mode but not in debug (one is a timeout, the other is an assertion)
Two of them are failing in both and I don't know why I marked them as succeeding.

ie did some quick debugging and added test notes

needed because of how we symlink things

test_itertools was failing because of a version mismatch between the test and the implementation we copied

For some reason the max-RSS limit doesn't seem to be kicking in.
Switch to putting a limit on the virtual size instead, and bump the
limit from 500MB to 1.5GB.

to not conflict with CPython's -O.  They're quite similar
(increase optimization level), but some tests ask for -O when
they don't really want our version of it.

Main difference is lowering the recursion-depth on unoptimized
builds, since we need more stack space per python frame.

We symlink the CPython tests into our tests directory to control which
ones we will attempt to run.  A bunch of the tests though need other
test files in order to run, and we hadn't symlinked those in.

At some point we should switch to symlinking the Lib/test directory instead
of individual files, but for now this helps.

[WIP]Let GCC 5 happy and update the CPython test notes

Be able to run an unmodified virtualenv

These cpython tests are working now

Which are quite hard to reproduce because they depend on the details
of the C stack.

Anyway, we should probably start using the recursion-depth-tracking functions
in more place, rather than getting segfaults.  There are a lot of CPython tests
that test for recursion-depth-checking.

Fix some corner cases in the irgen refcounter, and fix a refcount
issue in the bz2 module itself.

Do it by patching distutils, which setuptools I guess builds on

Well, really an unmodified pip+setuptools

The last piece is py_compile.  Just shim that back into our parser
to get the parser to write out a pyc file.

It seems like we don't even need this -- most callers of py_compile
(or at least, virtualenv), don't seem to care if the compile step
passed or failed.  But while we're here, try to support it.

Switch to CPython way to build standard C extensions.

Merge AST/BST work into master

AST: deallocate nodes

Use a bumpptr allocator to keep track of the AST nodes.
I could not use the LLVM one because it does not call the destructor on allocated elements.

AST & BST: remove unnecessary nodes and fields + little less memory usage

Disable some extensions, part of because they were handled by
from_cpython/CMakefile.txt, part of beacuase we need to enable it in
seperated PR. Such as tk extension.

And also add some modifications to let extension can find the source
code in correct path.