Don't emit duplicate attr guards

pyston (calibration)                      :    0.8s stock2: 0.8 (+2.5%)
pyston interp2.py                         :    5.9s stock2: 6.2 (-4.5%)
pyston raytrace.py                        :    6.9s stock2: 7.0 (-1.6%)
pyston nbody.py                           :    9.8s stock2: 9.6 (+1.9%)
pyston fannkuch.py                        :    7.0s stock2: 6.9 (+2.6%)
pyston chaos.py                           :   20.6s stock2: 21.6 (-4.6%)
pyston spectral_norm.py                   :   27.9s stock2: 34.2 (-18.6%)
pyston fasta.py                           :   17.1s stock2: 17.8 (-4.5%)
pyston pidigits.py                        :    4.4s stock2: 4.5 (-1.0%)
pyston richards.py                        :   10.4s stock2: 10.2 (+2.2%)
pyston deltablue.py                       :    2.2s stock2: 2.2 (-1.9%)
pyston (geomean-0b9f)                     :    8.8s stock2: 9.1 (-3.2%)

We should do a more comprehensive investigation.  Removing t2 caused
regressions on a number of benchmarks since we lost chances to do
speculations, but making t3 easier to get to caused regressions
due to the cost of our LLVM optimization set (which is pretty hefty
since it's supposed to be hard to activate).

Fully switch to the new deopt system, and clean up a lot of stuff.

A "FunctionSpecialization" object really makes no sense in the context of
an OSR compile, since the FunctionSpecialization talks about the types
of the input arguments, which no longer matter for OSR compiles.
Now, their type information comes (almost) entirely from the OSREntryDescriptor,
so in most places assert that we get exactly one or the other.

We only needed that for supporting the old deopt system

Long live new-deopt!

Before we would do type analysis starting from the function entry
(using the specialization of the previous function).  This makes things
pretty complicated because we can infer different types than we are OSRing
with!  Ex if the type analysis determines that we should speculate in an
earlier BB, the types we have now might not reflect that speculation.

So instead, start the type analysis starting from the BB that the OSR starts at.
Should also have the side-benefit of requiring less type analysis work.

But this should let us get rid of the OSR-entry guarding, and the rest of
the old deopt system!

add a simple_destructor for file objects

Add third GC arena

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)

add a comment about further work for realloc(), and factor out the duplicate list.forEach in large/huge arenas

don't use toggle, since our assert ensures not free only in debug builds.  also, more valgrind error disabling for access to the GCAllocation data

port over sgen's idea of LOSSections as a mid-sized arena, so that we now have:

SmallArena original non-large allocator, free bitmaps, segregated-fit allocator.
  handles objects where size <= 3584 bytes
LargeArena (new code, size-specific free lists.)
  handles object  where 3584 < size <= ~1 meg
HugeArena (original large allocator, 1 mmap per object.
  handles objects where size > ~1meg

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.