I'm surprised we got away so long without handling them!

Also, it looks like del statements go through full tuple unpacking --
so you can do something like
del (l[1], [c.b])

So that we have a whole number of pointers to scan.  I think there's a bunch
more we can do to optimize this situation (do we even need to scan these at
all?) but this seems like the simplest way to make this work for now.

Need to unbox-rebox bools like we do for ints and floats.

Also, improve rewriting to still be able to rewrite object construction.
For now, be able to rewrite the case that a function takes kwargs but
the kwargs is empty.

Also, add an even faster path to typeCallInternal.  This is partially
obviated by the improved rewriting, but we might as well keep it.

And add a test that would have caught this specific case.
Would be nice if we had some way of verifying these more generally...

I don't think the current implementation will be that fast
and will probably do poorly in sort()/sorted() microbenchmarks.
My feeling is that it doesn't matter that much, but if it does
there are some things we can do to optimize it.

Unwinding: remember the bounds of the interpreter function

for -I and 'import optparse' this will result in about 5% speedup

The InternedString change conflicted with Travis's keyword-params change,
since the arg names were switched to InternedStrings.

I decided to not intern the param names any more, and instead represent them
as llvm::StringRef.  Another option would be to intern the builtin ones, even
though there's no independent benefit to doing so, since that would let us use
InternedStrings more generally.  Probably the "best" but most complicated would
be to have the StringRef version and then an InternedString version as well
that was constructed when needed.

Getset set

Add the '__pyston__' module

it lets scripts control some of the internal options
will be used for interpreter performance tracking

Also, move exceptions.py since that conflicts

moved array.py to array_test.py

Previously we were just passing around a vector<> of LineInfos; now, they
get encapsulated in a BoxedTraceback object.  This has a couple benefits:
1) they can participate in the existing sys.exc_info passing+handling
2) we can enable a basic form of the traceback module.

2 means that we can finally test our tracebacks support, since I was constantly
fixing one issue only to break it in another place.

1 means that we now generate the right traceback for the current exception!
Before this change, the traceback we would generate was determined using a different
system than the exc_info-based exception raising, so sometimes they would diverge
and be horribly confusing.

There's a pretty big limitation with the current implementation: our tracebacks
don't span the right stack frames.  In CPython, a traceback spans the stack frames
between the raise and the catch, but in Pyston the traceback includes all stack frames.
It's not easy to provide this behavior, since the tracebacks are supposed to get updated
as they get rethrown through each stack frame.

We could do some complicated stuff in irgen to make sure this happens.  I think the better
but more complicated approach is for us to create the custom exception unwinder we've been
wanting.  This would let us add custom traceback-handling support as we unwound the stack.

Another limitation is that tracebacks are supposed to automatically include a reference
to the entire frame stack (tb.tb_frame.f_back.f_back.f_back....).  In Pyston, we're not
automatically generating those frame objects, so we would either need to do that and take
a perf hit, or (more likely?) generate the frame objects on-demand when they're needed.

It's not really clear that they're actually needed for traceback objects, so I implemented
a different traceback object API and changed the traceback.py library, under the assumption
that almost-noone actually deals with the traceback object internals.

builtin functions

Remove -fPIC

add the array module

If we could statically determine that an object doesn't have a __nonzero__ method,
we would previously say that it had an undefined truth value (and then crash).

add richards.py and deltablue.py minibenchmarks

Migrate to (a subset of) CPython's file implementation instead of our own.