end the unwind session by setting the is_active flag to false.  if the unwind session isn't active we don't mark through the ExcInfo, so exceptions/tracebacks should get gc'ed properly.

1. remove the BoxedTraceback** argument from maybeTracebackHere.  the unwinding.cpp
   code can get it just as easily.
2. combine UNWIND_STATE_OSR and UNWIND_STATE_RERAISE into UNWIND_STATE_SKIPNEXT,
   since they share the same behavior.
3. put the SKIPNEXT behavior in the callers of unwindProcessFrame.  Now unwindProcessFrame
   does nothing but create a PythonFrameIteratorImpl (if it can), and if it can
   calls its callback with it.
4. initialize the unwind state to NORMAL in raiseExc.

move unwind_state to ThreadStateInternal.  move the class decl to threading.h and ensure the small/hot accessors are inlined

stop using 'WHY' just to be similar to cpython.  'STATE' is better.  also, reduce duplicate code in unwindProcessFrame

store the exception ferry (as an ExcInfo, not ExcData) within our internal
thread state, and explicit visit type/value/traceback at gc time.

This allows the gc to run during an unwind (a necessity since
we're allocating new BoxedTraceback instances)

Add a tb_next to the BoxedTraceback object, which during normal unwinding is how we add lines to a traceback.
For getTraceback() we take advantage fo the fact that each BoxedTraceback can have multiple lines in it, and
only create one.  Also add BoxedTraceback::Here which is kinda like PyTraceback_Here, except that since we
don't have access to the ExcInfo inside it, we have to pass a pointer to the BoxedTraceback*.

three wrinkles in traceback generation while unwinding are:

   1) if the previous frame was an osr frame (so we should skip the current frame)
   2) if the traceback object was passed to raise3, or raise0 was used (treated as a re-raise by cpython)
   3) the interpreter map

1 and 2 are fixed by keeping a per-thread interpreter state variable, "unwind_why" ("why" is probably
a bad name to use in this context, but cpython's logic uses that word as well), to record if we're in
either of those cases.  Both cases have the same effect (skip the next traceback line, and reset state
to NORMAL.)

The interpreter map problem comes about because of the way c++ unwinding works.  since ASTInterpreter::execute
uses RAII for RegisterHelper, unwinding through the frame causes us to jump to a cleanup block and then resume
unwinding (with the IP still in ASTInterpreter::execute).  Since the IP is there, we assume the frame is valid
and we can look up $rbp in the interpreter map.  Given that we just cleaned up the RegisterHelper (and removed
the $rbp mapping), we crash.

The fix here is to keep the same RegisterHelper in ASTInterpreter::execute, but the ip checked for by the
unwinder (and the $rbp in the mapping) correspond to ASTInterpreter::executeInner.

Lastly, AST_Interpreter::invoke catches exceptions, so we won't make it to the top-most ASTInterpreter::execute,
and so won't add the final line.  We make use of BoxedTraceback::Here here as well to add the final line.

Rewrite "a in b" expressions

add a stat for the number of times we abort a callattr rewrite because we had to call into python

add per-python line exception stats

Optimize creating tuples from lists

add logByCurrentPythonLine, and use it for skipped ics and exceptions (if the proper STAT_*_LOCATION #defines are enabled)

also adds two scripts (tools/ic_stats.py and tools/exception_stats.py) make the stats a little more manageable for these
cases.

small optimization to sre_compile._compile()

Skip initializing exc fields inside JITed code

Switch from expensive old-style-class iteration to our faster iteration.
We could/should probably make old-style iteration much faster than it currently
is for us (10x slower than CPython), but this is a pretty targeted change and
makes compiling regular expressions much faster: it cuts (non-LLVM) _compile()
time by 2x.

cache + reuse 1-length strings

Switch those to just calling 'new BoxedString' instead.

Not sure how much it helps, but it's mostly just a wrapper around
new boxedstring.

Also, I don't think it needs to be in inline/ any more since we
will always box strings during codegen rather than emit calls
to boxString.

CPython does this and seems like a good thing to do.  Otherwise
iterating over a string would cause lots of allocations.

One difference between this implementation and cpython's is that cpython
doesn't eagerly create them, and so it checks to see if they've been
created or not.

Even this is 2x slower

Temporarily disable type speculation

Unfortunately our type speculation strategy has bit-rot
over time, to the point that it's not super helpful.
Deopt (the flip side of the speculation) also has some bugs
in it which I was starting to trigger, so just disable the
whole thing for now.

Turning it off should just be a temporary measure and I'll
look soon into what we need to do to get it back on.

cmake change default build directory, configure script, Fedora support

-pyston build using the copied headers that include the generated pyconfig.h

Conflicts:
	.travis.yml

New benchmarks

Use BoxedString in codegen

Convert to BoxedString much sooner, and have any functions that
might need to box a string take a BoxedString.  This means that
on some paths, we will need to box when previously we didn't, but
for callsites that we control we can just intern the string and
not have to box again.  The much more common case is that we
passed in unboxed string data, but then ran into a branch
that required boxing.

BoxedString shouldn't be that much more costly than std::string,
and this should cut down on string allocations.

For django-template.py, the number of strings allocated drops from
800k to 525k; for virtualenv_test.py, it goes from 1.25M to 1.0M

A couple things made this not 100% mechanical:
- taking advantage of places that we could eliminate unbox/rebox pairs
- different null-termination assumptions between StringRef and the c api.