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

do 100 queries per insert instead of 1000 after all inserts.

cheetah's tests do a PATH search for the "cheetah" executable,
and since we were appending the test-cheetah's location to PATH,
it would find the system cheetah preferentially to the test cheetah.

This is fine since on most systems there isn't a system cheetah, but
somehow mine has one.  The system cheetah will invoke the system python,
which will end up passing more of the tests.

We could prepend PATH instead of append to it, but it looks like the
the tests don't need anything else, so for now don't pass in anything else
in PATH.

Include total-tests-run in our test-suite-results checking

I'm seeing fewer failures locally than specified in the file, and
I'm guessing it's because I'm somehow skipping some tests, but I'm
not sure.

this increases cpython time on _imperative.py to ~2 seconds (and lowers pyston's % from ~480% to ~380%).
the declarative benchmark takes 10 seconds for cpython with this change, but it doesn't work on pyston at all yet.

Add debug symbols to release mode.

_U_dyn_register: Use binary search to find insert location

change timers back to ticks

This reverts commit 89df764f.

Specify /bin/bash for the Makefile, as some distros may have other shells as /bin/sh

Specify /bin/bash for the Makefile, as some distros may have other shells (eg, ubuntu image for docker has /bin/dash)

Revert to using gettimeofday to have measurements in us instead of ticks.

Some capi/descr code cleanup

I think it now contains the same types that CPython's
descrobject.c handles.

more rewriting

It needs to reserve some special key values that the caller
has to promise to never insert into the map.  For integers that's
-1 and -2... which we were using and then got some random data back.

don't mmap such small regions

don't mmap such small regions - linux clusters page faults so the larger the regions we mmap the better, and larger regions don't cost us anything

ie in cases that we couldn't rewrite all of the argument conversion,
emit a rewrite that's just a call directly to callFunc, so we can skip
the earlier parts of the dispatching.

I think there is more we can do here though; there are also more places
that this kind of approach would be applicable.

Also removing logic in Stats::dump that counts the total number of ticks
in timers. It relies on specific timer naming conventions that aren't
currently being followed. If, at a later time, we are interested in
having the sum of timer ticks, we should refactor the code to have a
separate class for counters that log time.