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.

ie try to avoid api conversion.

something like 40x slower.  also, has some sort of super-linear overhead:
10xing the size of the benchmark takes 33x longer for us, but 10x longer
for cpython.  (Looks like it's coming from the GC)

We should hopefully be able to avoid getting here in the first place
though.

in order to save one register.
This makes it possible to pass up to 3 args to a runtimc IC callattr
(Runtime ICs currently don't support passing args on the stack)

add tpp_call for faster calling of non-functions

This register reuse here didn't go through our locations-tracking
infrastructure, and it just assumed it'd be ok to do.  I think it's
only called from places where the register we reuse won't be used
after this function.

This broke though when I added the ability to allocate orig-arg
registers; now, the argument is still dead in that it won't be used
by the function, but it could be "used" if a guard failed.  But this
wasn't being tracked in the locations map, so we ended up trashing
the orig arg despite the lengths we went to to not do that :/