Previously it was:
tier 0: ast interpreter
tier 1: llvm, no speculations, no llvm opts
tier 2: llvm, w/ speculations, no llvm opts
tier 3: llvm, w/ speculations, w/ llvm opts

tier 2 seemed pretty useless, and very little would stay in it.  Also,
OSR would always skip from tier 1 to tier 3.

Separately, add configurable OSR/reopt thresholds.  This is mostly for the
sake of tests, where we can set lower limits and force OSR/reopts to happen.

Generator tracebacks

add reversed() builtin function, as well as compatible __reversed__ methods on list/xrange.

Fix: GC must visit the 'iter' field of every BoxedIterWrapper

(previously we would just throw an assert)

Implement str.join(iterable)

We were having problems with spawning subprocesses from threads,
since the children would inherit the "wait for another thread to acquire
the gil" flag, but would not inherit the thread that would actually
try to acquire the gil; this would make the child hang.

before we stopped at the generatorEntry func and did not unwind
into the caller.

Also, register string memory as additional GC pressure.
The subprocess module repeatedly allocates a 1MB str as a buffer
for reading from file descriptors.  The first issue was that we would
never free this memory; but even once we would, we wouldn't trigger a GC
since there were only small GC allocations (sizeof(BoxedString) at a time)
but with large other memory pressure, so add a hook for adding GC pressure.

We don't call pthread_join on the threads we create, so apparently
unless we call pthread_detach we just don't get the resources back
(ex stack memory).

This doesn't handle all the cases that CPython does.

And fix a bunch of places that they weren't.

This might introduce a perf regression (ICs get slightly slower) but cleans
things up a lot and fixes a few bugs.

We clear a patchpoint by writing a jmp-to-slowpath at the beginning.
But there could be a stack frame currently inside the IC, and we
need to be able to invalidate the IC while letting the other frame
return successfully.  So make sure that we don't overwrite
any potential return address.

Before, we tried to do it based on whether the rewrite we were
adding was "compatible" with whatever was already in there.  But we
weren't really doing this and there were a lot of limitations with this
method anyway.

This is kind of hacky due to our method of first doing the rewrite,
and then picking the slot to rewrite to.  This means that at the time
that we create the rewrite, we don't know the exact location of the
"num_inside" counter, so we have to go back at the end and rewrite it.

We could also switch things to pick the rewrite slot first, but that
is also complicated but perhaps more subtly, since during the course
of the rewrite the chosen slot could have gotten rewritten!

This changeset adds this functionality but doesn't use it for anything.

Thanks to @denji for the report!

We weren't scanning it as part of the gc handler, so eventually it would
get collected and then __name__ would break.  (un)fortunately, in the
cases that would use it, it looks like it would always get replaced by
another string (the only thing being allocated out of that size bin?),
so it would look like the __name__ was just wrong.

Anyway, this should fix interp2.py

I'm surprised we got away so long without handling them!

Also, it looks like del statements go through full tuple unpacking --
so you can do something like
del (l[1], [c.b])

So that we have a whole number of pointers to scan.  I think there's a bunch
more we can do to optimize this situation (do we even need to scan these at
all?) but this seems like the simplest way to make this work for now.

Need to unbox-rebox bools like we do for ints and floats.

Also, improve rewriting to still be able to rewrite object construction.
For now, be able to rewrite the case that a function takes kwargs but
the kwargs is empty.

Also, add an even faster path to typeCallInternal.  This is partially
obviated by the improved rewriting, but we might as well keep it.

And add a test that would have caught this specific case.
Would be nice if we had some way of verifying these more generally...

I don't think the current implementation will be that fast
and will probably do poorly in sort()/sorted() microbenchmarks.
My feeling is that it doesn't matter that much, but if it does
there are some things we can do to optimize it.

Unwinding: remember the bounds of the interpreter function

for -I and 'import optparse' this will result in about 5% speedup