My hunch is that code density is more important than avoiding
ome of the `if (rewrite_args)` checks.

Also add some hacks to get rid of the func-name-getter-as-lambda,
so we don't need to templatize on that either.

Results of this commit are kind of mixed:

       django_template3_10x.py            13.6s (2)            13.8s (2)  +1.4%
 sqlalchemy_imperative2_10x.py            18.8s (2)            19.0s (2)  +1.2%
            pyxl_bench2_10x.py            10.7s (2)            10.1s (2)  -5.1%
                       geomean                14.0s                13.8s  -0.9%

And add an optimization that in the fast paths, we don't incref any args.

This function is complicated because it has so many return values (out-parameters).
It also returns a decent amount of information about what the caller has to do
after it is done with the args (decref them, decref the rewritten ones, etc), and
the contract was getting very complicated.  It also had some complicated rules
about how the caller had to set up certain input arguments.

I also tried adding some optimizations to it, where it would sometimes not incref all
of the returned args; I tried continuing the current scheme by passing back some information
about which args needed to be decref'd or not.  This was really messy and was also a
perf hit.

So instead, switch it to being callback-based.  I think this should clean it up quite a bit
and also open up some room for more optimizations.

This commit is just a refactor -- it changes the name to rearrangeArgumentsAndCall, which takes
a "continuation" callback.  For now it just calls rearrangeArguments under the hood.

checkAndThrowCAPIException needs to do a 32bit comparison in some cases

this should fix a very annoying rarely encountered issue...

check return value instead of calling checkAndThrowCAPIException()

this should make pyston more robust to cases where the error is set by a previous operation

no functional change intended

refcounting changes for our integration tests

Otherwise old build directories will switch to not having refchecking.

this fixes and reenables some of our integration tests

this gets triggered by M2Crypto which sets an error but returns None.
previously we throw the error in the non rewriter path and ignored it in the rewriter.
this makes it now identical and mote like cpython does it (only looks at the return value)

the fixed blocksize of our region allocator was too small for very large actions
fix this by using the more powerful llvm::BumpPtrAllocator which handles allocation larger than the slab size

previously we checked if NDEBUG was defiend but this caused problems with extensions which modified this define

interpreter: mark created_closure as live variable inside yields

without this we would never traverse the variable and the GC would therefore be unable to destroy the generator

The issue with django was that it called object.__dict__.__get__(unicode),
which would convert object to dict-backed, and then our shutdown logic doesn't
support that case.

The shutdown logic still doesn't support that case, and there are other ways
to convert object's __dict__ to being dict-backed, so this commit isn't a full
solution, but it seems like something we should do anyway.

Try to reduce JIT time for the LLVM tier

I was worried we were in trouble since we don't always pass an owned
reference to any arguments filled via defaults, but for Python functions
this is fine since we will end up creating our own reference to it.
For builtin functions, we disallow changing defaults.

Not sure if it matters, but there are some cases that our
refcounter will add decrefs earlier than CPython would, if it
can prove that the variable won't end up getting used.

One example is in:

for i in foo():
  break

The iterator object (`iter(foo())`) will not get used after the first
call to next().  So our system will put the decref at the top of the loop.
CPython will do the decref after the loop exits, like normal.

and switch the llvm tier to use them instead of its own analysis

Apparently they are slowing down the irgen phase in debug mode quite a bit,
since a lot of the time is dominated by InternedString hashtables.

I think this is the main source of our jit-time regression.

This time, structure it a different way,  This does a better job of
highlighting the JIT-time regression from the refcounting branch.

Enable the gcc build

The release CI builds are failing since they run the extra tests

Fix usage of undef variables

I think I had gotten confused and mixed up "undefined variables" (Python
variables which hadn't gotten set) and "undefined values" (results of
expressions that the JIT knows will throw, or otherwise can't evaluate).

For undefined *variables*, we represent them using None, since they can
still have refcount operations done on them.

For undefined *values* (or results), we can use llvm's undefValues, since
they should never be touched.

I ended up running "make update_section_ordering" multiple times since it seemed to help.
Or maybe things are just very random and then I picked one that happened to benchmark well.

This should fix the bad behavior we had where setGlobal would only get rewritten
by having its call to setattr() get inlined, and having setattr() then think it
was being called directly.  This was both brittle (only worked on release builds)
and incorrect (there were checks that happened before calling into setattr, which
needed to be emitted as guards).

I had hacked in an attribute((always_inline)) to at least deal with the brittleness,
but this should be a fix for real.  And let us reenable the gcc builds.

Otherwise they can end up seeing the return address of their caller

Fix the last two reffail tests