Add a new JIT tier which is tightly coupled to the AST Interpreter

For issue #254, add lt, le, gt, ge to old-style class

assembler: Use 32bit moves if the immediate fits inside 32bit

makes the encoding 4-5byte shorter and works because the upper 32bit will get auto cleared

This JIT is tightly coupled to the ASTInterpreter, at every CFGBlock* entry/exit
on can switch between interpreting and directly executing the generated code without having
to do any translations.
Generating the code is pretty fast compared to the LLVM tier but the generated code is not as fast
as code generated by the higher LLVM tiers.
But because the JITed can use runtime ICs, avoids a lot of interpretation overhead and
stores CFGBlock locals sysbols inside register/stack slots, it's much faster than the interpreter.

Use less large constants

Preperations for the new JIT tier

Conflicts:
	src/core/types.h

IC sizes are guessed...

It deleted the passed ICSlotRewrite* and there was no way for a caller to know this without looking at the source.
Make the ownership explicit by using a std::unique_ptr

and make code ready for the new JIT tier.

Conflicts:
	src/runtime/iterobject.cpp

add -a flag which outputs assembly of ICs

build sorted vectors for large/huge objects at gc time, and use binarySearch to power ::allocationFrom

fastpath investigations

I think this only gets hit through explicit calls to tuple(),
but at one point it was crashing on this codepath which is
how I noticed it.

Our tuple format is now the same as CPython's, so we can just enable
the fast macros again.

Little bit of trickiness since they declare their storage array to
have a size of 1; I'm not sure how important that is, but let's
play it safe and match it.

We already have this for the rest of our code, but it
wasn't enabled for C files.

- conservative references into the large/huge heaps are especially expensive
- it's nice to know what kind of object we are scanning

So we can compare against their latest instead of whatever was in apt.

Notably, to the rewriter.  Turns out that a decent amount of the time that
used to get allocated to slowpaths is actually time spent in the rewriter,
doing successful rewrites.

Take another pass over the failing cpython tests

Switch BoxedMethodDescriptor to tpp_call

While it's bad that we do so poorly with large heaps,
that's not the point of this benchmark.

- "Override" the stattimer stack while we are throwing an exception.
- Mark some more things as being back in "builtins" code.

Minor, but should cut down on some overhead

reduce api conversions

We got away with sloppy exception clearing in some places, since
raiseExcHelper would end up calling typeCall which would re-throw
the capi exception that hadn't been cleared.

Now that typeCall doesn't do that (which is fine), those bugs got
exposed.

We can't rewrite into the object-creation behavior, but
we can rewrite the decision to just use CPython's c slots.