fixes #169 - allow a negative step in xrange

Previously it would always link against the system libstdc++; not sure how
that was working.

Also, put that in its own included makefile so that we can track the dependence
on the configuration parameters (otherwise you would have to run a configuration
manually to get this change).

Make some things owned by the cf rather than using global registries,
so that 1) we can eventually free the right things when we start freeing
cf's, and 2) we can have a single ip->cf mapping instead of lots of
ip->other things mappings.

Also added some helper classes for making stack crawling easier.

fix header ordering in codegen/entry.cpp

Had to improve some of our rewriting; looks like there
must have been an LLVM commit that changes the live-out registers
we see.

Also, temporarily disabled format-checking: the rebase
updated clang-format, which now is formatting a few files
differently.  Will re-enable and re-format in the next commit.

Bunch of fairly-simple API changes to contend with.

Main problem is we're still running into those debuginfo issues.

Add tp_call handling, a couple random functions, and
allow GC-aware objects (though we don't do much with them).

ie "[a, b] = 1, 2"

The issue was that if we transformed the AST nodes corresponding to scopes,
we wouldn't be able to match the initial analysis with the subsequent queries
to the transformed AST nodes.

We had run into that before, but worked around it by just modifying the AST
nodes in place.  For generator expressions that wasn't a possibility,
so now we explicitly registers when we replace scope-related AST nodes.

looks like the memory leak in go.py is not coming from our heap (strings?)

Add some more slightly-modified benchmarks, but also make it easier to run them from the pypy directory

which would eventually cause stack space exhaustion and segfault.

disable rewriting

reduce(), some float precision issues, string interpolation improvements

(more) correct semantics for import

I guess these will always be the same thing which is why it works,
but it's still wrong :/

Use call_done_guarding to defer the call to setDoneGuarding
until later.  As messy as it is, I guess this was the point of
the more_guards_after passing tha we had.

We'll have some issues with typeCall if the __init__ func wants
to set some guards too, since those will happen after __new__
was already called (too late for guards); we'd have to figure
out how to get __init__ to do all of its guards before calling
__new__.  (This applies even if we try to do it in multiple passes,
since we wouldn't have a "all guards before any mutations" flow.)

(which has flipped value)
should hopefully be more clear what this is for -- at least
I hope that's what this is for.

Also fix a GCC warning... not sure if this is supposed to be better though.