The default is 64, which is quite a lot for our uses.

- add note + license
- put in our namespace
- change header guards
- make it match our lint style
- don't apply our formatting

With no modificaions in this commit, so that we can track changes.
Unmodified from llvm rev r230300.

when calling a BoxedWrapperDescriptor don't create a BoxedWrapperObject

- use callattr directly instead of getattr+runtimeCall
- compvar: teach it that None is never nonzero

BoxedWrapper optimizations

In order to allow rewrites.
I'm wondering if we can't enable this for more classes...

Before we created a tuple just to pass 1 or 2 args and then immediately extracted them
and destroyed the tuple again.

Move closer towards exposing the public gc interface only in one file.

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"