also keep a free list of chunks around to make subsequent collections faster.

results in TraceStack::pop and ::push being inlined and disappearing from the perf report (::push was at 3.99% before).

Also drops aggregate GC times for ray trace by ~5%.

before: gc_collections_us: 2151827
after: gc_collections_us: 2023809

Should probably nuke all of the codegen "memory management" using vrefs,
and instead just used shared_pointers.  Looks like there could be more
"bugs" of the kind fixed in this commit...

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