if we OSR out of a function, make sure we use the same exception
style for the OSR'd version.

We could also have the OSR exit code deal with switching exception
styles, but for now it doesn't feel worth it.

I had added the ability but forgot to turn it on.

Also, allow reraising using CAPI exceptions.

Clean up our exception handling

I use like to use test/tests/t.py and t2.py as temporary test files,
so that they can get hooked into the makefile helpers, but the tester
ignores them.  Do this for t3.py too.

It was pretty unwieldy and handled some disparate parts of the
exception-raising process.  I think things are a bit cleaner now:
- cxx_unwind.cpp handles C++ unwinding semantics
- unwinding.cpp converts C stacks to Python stacks
- exceptions.cpp takes Python stack frames and handles them appropriately

So for throwing a C++ exception, it starts out in cxx_unwind.cpp, which
then hands off the C frames to unwinding.cpp, which then hands off the
Python frames to exceptions.cpp.  When we get exceptions not via uncaught
C++ exceptions (ie explicitly handled C++ exceptions or CAPI exceptions),
those go directly into exceptions.cpp.  There are also non-exception cases
that we want to get the Python stack trace (ex sys._getframe), and those
are handled by unwinding.cpp

We have a couple different ways of walking the C stack
(C++ exception unwinding and non-destructing stack crawling),
and they both want to do this to reconstruct the Python stack.
Extract out the common code.

It had gotten pretty ad hoc.  There were two things it was doing
- some things dealing with unwinding; moved those to codegen/unwinding.cpp
- most of our exception-throwing logic; moved these to a new runtime/exceptions.cpp

Be able to jit functions that throw CAPI exceptions

In theory should help with pyxl which throws a decent number
of StopIterations from calling generator.next() directly, but
pretty few of those calls actually make it into the llvm JIT
to benefit from this.

(Not enabled yet)

Our IR doesn't explicitly represent the data transfer between an Invoke
statement and its corresponding LandingPad.  We use a couple different
techniques to pass it through: in the ast interpreter/bjit, we stash it
into an interpreter-local variable and then pull it back out.  Previous
to this change, in the LLVM tier we would pass it directly through
an exception, using either the C++ or CAPI exception-passing mechanism.

This works but is a pain, since it requires coordination between the invoke
and the landingpad.  These live in different basic blocks, so we ended up
having this other code that lives separate from the normal irgen that has
to decide which exception style to use, and it has to respect certain
restrictions within irgen (ie it has to be careful to not request CAPI
exceptions for cases that we haven't added support for yet).

This commit changes the approach so that the exception data is passed
directly as LLVM Values, and its up to the Invoke to figure out how
to get it into that form.  This adds a bit more complexity to the invoke,
but it should make the interface easier to extend (such as in the next commit).

Which piggy-back on the integration tests for getting their dependencies.

fix a few generator problems

this all showed up by running test/cpython/test_generators.py
sadly there are still a few until we can run the whole test

Rewrite unaryop and property get

more capi exceptions

I think we track the dependency correctly in cmake, but distutils
doesn't know that the system headers can change from underneath it,
so manually specify them as extra dependencies.

Previously, if a CAPI-style callsite tried to call a function but
only CXX versions were available (and visa versa), it would bail
on rewriting.  Now enable CAPI rewrites of CXX functions by using
a helper function, and enable CXX rewrites of CAPI functions by
just calling checkAndThrowCAPIException like we normally do.

note: people need to `find -name '*.pyston.so' -delete`, since although
I think we correctly know to try to rebuild the sharedmodules,
distutils won't end up rebuilding it.

and friends.  Should be pretty much the last step for letting
calls go all the way through our runtime using CAPI exceptions.

add __doc__ attribute to capifunc

Refactor location and names of gc visit functions.

This serves two purposes.
1) Improve naming consistency (follow the format TYPENAME::gcHandler)
2) In the source file, the visit function declaration is closer to the
   fields of the objects. If a field is added, hopefully it will be
   easier to remember to update the GC visit function.

Add "doctest" support

My guess is that there's a build dependency issue, where
we try building files that include libunwind.h before we
run the rules that generate it.  Not sure why we weren't running
into that before.  But the normal c++ files in src/ correctly
depend on libunwind, but the ones in src/runtime/inline don't
seem to.

For good measure, don't include libunwind.h in our header files,
and just use forward-declaring.