build sorted vectors for large/huge objects at gc time, and use binarySearch to power ::allocationFrom

fastpath investigations

I think this only gets hit through explicit calls to tuple(),
but at one point it was crashing on this codepath which is
how I noticed it.

Our tuple format is now the same as CPython's, so we can just enable
the fast macros again.

Little bit of trickiness since they declare their storage array to
have a size of 1; I'm not sure how important that is, but let's
play it safe and match it.

We already have this for the rest of our code, but it
wasn't enabled for C files.

- conservative references into the large/huge heaps are especially expensive
- it's nice to know what kind of object we are scanning

So we can compare against their latest instead of whatever was in apt.

Notably, to the rewriter.  Turns out that a decent amount of the time that
used to get allocated to slowpaths is actually time spent in the rewriter,
doing successful rewrites.

Take another pass over the failing cpython tests

Switch BoxedMethodDescriptor to tpp_call

While it's bad that we do so poorly with large heaps,
that's not the point of this benchmark.

- "Override" the stattimer stack while we are throwing an exception.
- Mark some more things as being back in "builtins" code.

Minor, but should cut down on some overhead

reduce api conversions

We got away with sloppy exception clearing in some places, since
raiseExcHelper would end up calling typeCall which would re-throw
the capi exception that hadn't been cleared.

Now that typeCall doesn't do that (which is fine), those bugs got
exposed.

We can't rewrite into the object-creation behavior, but
we can rewrite the decision to just use CPython's c slots.

ie try to avoid api conversion.

something like 40x slower.  also, has some sort of super-linear overhead:
10xing the size of the benchmark takes 33x longer for us, but 10x longer
for cpython.  (Looks like it's coming from the GC)

We should hopefully be able to avoid getting here in the first place
though.

add tpp_call for faster calling of non-functions

This register reuse here didn't go through our locations-tracking
infrastructure, and it just assumed it'd be ok to do.  I think it's
only called from places where the register we reuse won't be used
after this function.

This broke though when I added the ability to allocate orig-arg
registers; now, the argument is still dead in that it won't be used
by the function, but it could be "used" if a guard failed.  But this
wasn't being tracked in the locations map, so we ended up trashing
the orig arg despite the lengths we went to to not do that :/

It used to get away with telling other functions that it had
already guarded its args, since it could rely on the fact that
it could only get called through the path in runtimeCallInternal
that would guard the args.

Now that it can be called through the tpp_call fastpath (which maybe
should just guard the args), it has to guard them itself.

Could be faster with templates but seems roughly even for now.

Similar to ArgPassSpec.  Previously we kept them on the CLFunction,
but there are places where we want to specify a certain parameter
signature without having a clfunction available.

travis-ci compile and test in single step

Temporary fix for freeing-classes-before-instances bug

Was running into it, so just added a quick fix that should hopefully
get us through until rudi gets in his real fix.

This commit just delays freeing the class objects until the end of the
sweep.  It doesn't deal with a number of corner cases such as if
a class and a metaclass get freed at the same time (they both get delayed
to the same point), or if we free a class with weakrefs to it (it just
gets treated like a normal weakreferent).

Don't have cheetah_test look for system cheetah