Rewriter "aggressiveness" and backoff

We often have cases where the "attr" part of a callattr can be rewritten but
the "call" part cannot.  This change lets us be able to rewrite the getattr
and then write out the call as a call just to runtimeCallInternal.

Add a concept of rewriter "aggressiveness" that decreases over time.
It starts off high and we will try to rewrite everything fully, but
as we succeed too often (megamorphic) or fail to rewrite, we will
decrease the aggressiveness and produce more generic rewrites.  This
means they are more likely to succeed both at the rewriting stage
and at the execution stage.

Previously, we would inspect the combination of (return_value, exception_state)
to try to determine what the behavior of future rewrites will be.  For example,
if no attribute was returned and no exception was thrown, then we would assume
that all future times through the rewrite the behavior would be the same.  This
has caused a few bugs, and I'm about to add other cases where it won't be possible
to examine the current function's return value to determine what the future
rewrites will do.

So instead, have getattr-like functions return a "rewriter return convention" flag
that says how future rewrites will behave.

3-arg execfile

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