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.