Doesn't support continue/break/return yet

last_exc was not thread safe, and didn't respect frame-localness.
Now that we have sys.exc_info support we can do this the right way

Seems like it kinda works

Currently nothing sets that though.

We were using the same .d name for the debug and release
versions of the pch, which would cause them to not get rebuilt
sometimes, and then clang would complain.

This seems like a cleaner way to allow type-specific codegen -- make
all types by default defer to UNKNOWN's handling of unpack().  Override
the unpack() method in [Unboxed]TupleType to do the unpacking statically
if possible.

ie we now can handle catching the new ExcInfo objects from JITted code.

This should also allow try-finally blocks more easily.

ExcInfo is a triple of exc_type, exc_value, exc_traceback -
analogous to Python's sys.exc_info().  Previously, we were just
throwing exc_value.

I still don't understand all the rules for when type(exc_value)
is not necessarily exc_type.  But this also makes it easier to
pass exc_traceback around, and should make it possible to make
our handling more consistent.

This commit just changes the runtime; the generated code currently
still expects a Box* to be thrown and will crash.

Don't pass that particular command line flag to the pch compile.

Fixes #192

Sometimes you want the wrapping behavior or not --
the builtin iter() function was calling getiter, but shouldn't
be doing this wrapping.

At runtime, we can detect if something supports the new Pyston iteration
protocol (__hasnext__) or not.

Statically, when we lower a for loop, we assume that the iterator supports
the new protocol, and we can't check it

This commit adds a check to getiter() which wraps a Python-style iterator
with an IterWrapper which adds the __hasnext__ method.

I think this addresses most of the remaining cases where we
have a traceback including "Line 0".  Most of these Name nodes
can't cause an exception themselves, but other nodes copy their
lineno values from these nodes, so just go ahead and set them
appropriately.

The previous changes increased -O execution time, showing up mostly in
definedness analysis and type analysis

I guess that makes sense, since we're adding additional symbols that
we then have to analyze.  We should make the analyses faster in general.

For now, just eliminate some of the unnecessary symbols that we're generating.
We only need to create the NONZERO temporary if we need to care about exception
state, so if there's no exception handler, just skip the temporary and generate
a nested structure.

They do a refcount==1 optimization, where they mutate a tuple
if they see that it isn't shared.  I don't know if we can have
a good way of supporting this.

Maybe we can always tell extensions that refcounts are >1?  Not sure
if there's any macro magic we can do to make "obj->ob_refcnt" return
something of our choosing.