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.

I think there are a couple ways we can go about this.  It looks like
extensions just specify tp_dictoffset if they want their instances
to have instance attributes, but don't usually actually look at the
dict or really make use of the fact that it's a real dict.  So possibly,
we have the ability to stuff a non-dict into the slot they reserved for
us.

Seems risky though.  Instead, the approach in this commit is to create
an actual dict and put it in like they expect.  All the attribute-accessing
paths have been updated to look at both the fast Pyston HCAttrs method, and
the CAPI dict method.

Apparently we can run quite well in the presence of GC bugs.
(We were scanning most extension objects using our Pyston scanner
instead of the conservative one.)  I am both relieved and terrified.

And now things work!

Use operator new() to get access to tp_alloc in a C++-ish way.

Instead of passing the object's class to the constructor, pass
it to new().  We need to do this since the class gets to pick how
the object gets allocated, including how large it will end up being.

Unfortunately it looks like defining an operator new on a subclass
hides the operator new from a superclass, even if they have different
signatures.  Macros to the rescue.

Add a PYSTON_NOEXCEPT define that gets defined to "noexcept" in C++ mode,
and to the empty string in C mode.

I don't think 'extern "C"' implies noexcept.

This is partly for better performance when we know that a function cannot throw
an exception, but also as an annotation for us since the exception model is
the main difference between C land and Pyston land.

Vim substitution: %s/\(\<PyAPI_FUNC\>(.*).*(\([^)]\|\n\)*)\);/\1 PYSTON_NOEXCEPT;/gc
- This will catch almost all cases, except for functions not marked with PyAPI_FUNC
  and function definitions that have extra paretheses (in comments, usually)

We're starting to have more functionality from CPython than we
wrote ourselves -- I think this is a good thing, but we should switch
Pyston code to calling it rather than supporting duplicates.

After I finish adding this stuff I'll try to clean things up a bit.