Since we don't memset the unicode allocations any more, and
we now use a precise gc handler, we have to be careful that
unicode objects are valid enough whenever a collection could
happen.

The issue was that "unicode->str = gc_alloc(...)" could cause
a collection, in which case the collector would go and see a
bogus value in the ->str field.  Now, do the str allocation
first (since it is UNTRACKED) and then do the precise allocation
second.

Inlining the allocation + object initialization saves
a decent amount of overhead, since most of the properties
will be fixed.  For example, the size of the main allocation is
fixed, so we can directly allocate it from the correct SmallArena
bucket.  We can also skip all the indirect function calls.

add babel to our extra tests

baseline jit: patch block transitions to a direct jump.

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

Before we emitted a runtime check to check if the block has been JITed or if we have to fallback to the interpreter.
Now we always generate a exit to the interpreter if the block is not yet JITed and patch the exit to a direct jump
later when we have successfully generated code for the new block.
This also removes the epilog and replaces it with a direct 'leave ret' combo which saves space and an additional jump.

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