Rewrite some more typeCall cases

Some random runtime function optimizations

misc small perf improvments

I don't think it's that important overall but it seems to be a decent percentage
of the time to enter the interpreter/bjit; this commit saves about 10% in a silly
ubenchmark.

When we call a __new__ we know nothing about, we have no idea what __init__
function we may or may not need to call.  So emit a call to a helper function
that will take care of that for us, which isn't itself any faster but lets
the rewrite succeed.

Small improvements to reduce the size of rewrites

Mostly around trying to avoid calling callattr().

If a jump offset is larger then 0x80 the instruction encoding requires 6bytes instead of 2bytes.
This adds up quickly, thats why we will try to find another jump to the slowpath with the same condition with a
smaller offset and jump to it / use it as a trampoline.
The benchmark show that this increases the performance slightly even though it introduces additional jumps.

Some reorganization of CLFunction/BoxedCode code.

- The code_obj field of CLFunction should be private since we require
  the use of an accessor there.
- Move some functions implementations out of headers.
- Put static methods into class.

This reduces the number of c++ exceptions we throw for iterators writen in python

Fix "error return without exception set"

Based on Marius's #865, with some extra checking and a test.

more getattr rewriting

Class gc fix: integrate with the finalization logic

I was noticing that classes were getting freed a few
collections after they were seen to be not-marked; the
issue with the old keep-classes-alive implementation is
that it assumed that !isMarked() implies that the object
will be freed in the sweep phase.  With the finalization
ordering, this isn't true.  We could move the ordering
before the keep-classes-alive behavior, but then the
finalization ordering might get things wrong since it
wouldn't see the final set of mark bits.  So I think
we need to integrate the two phases.

I think it ends up working to just say that type objects
have ordered finalizers, even though they typically don't;
I think this gets us the guarantees we need.

Fix and reenable type speculations

we were checking if the functions retrieves the exact same number of args as our calling convention requested this failed for varargs.
I encountered this while running test/cpython/test_math.py

travis-ci encountered sometimes a crash while running test_math.py.
This should fix the issue (the routines are used when creating a float from a string constant)

By moving the deopt logic into an inner frame.  I think we trigger
the isDeopt() block twice since there's a destructor that has to
get run.

Reduce some codegen allocations

Don't malloc-allocate rewriter lambdas

This commit works by adding a SmallFunction class that behaves
like std::function, but allocates its data inline rather than through
a separate allocation.  It probably could have also worked by taking
a custom allocator and using the new RegionAllocator.

It adds a bit more restrictions than std::function does (the types
caught by the closure have to be more "trivial" than std::function
supports), so some of this change is marking some types as trivial,
or copying data into a trivial format from things that aren't (ex SmallVector).

We were storing and passing them as std::unordered_map (and sometimes
switching to std::vector).  But the set can only contain the integers
0 through 15, so just represent it as a bitset.

Maybe a better overall approach is to not convert it out of its
original flat format; we keep that original memory around anyway
and I don't think it's that much faster to scan than our parsed
version.

But for now, optimize the current approach:
- convert vector->SmallVector
- call ensure since we usually know how many elements the vectors will have
- use a StringMap instead of an unordered_map<std::string>