By adding a 'is_kill' flag to AST_Name nodes, which say that
this is the last use of this name.  This handles some common cases
of keeping temporaries alive for too long.

For some rare cases, there is no AST_Name that is a last use:
for example, the iterator object of a for loop is live after
every time it is used, but dies when exiting the loop.

For those, we insert a `del #foo` instead.

The interpreter and bjit use these flags to remove temporaries
from the vregs.

The LLVM jit ignores them since it has its own way of handling
lifetime.  It ignores any `del` statements on temporary names
as an optimization.

This does not handle decref'ing temporaries on an exception.

Large dict literals would crash the bjit since it would try to allocate
scratch space to store all of the keys+values on the stack.

This is also, in a small way, detectable to the user, since we would evaluate
all subexpressions before doing any dict operations (which could trigger
__hash__ and __eq__ calls).  I started working on this, but it looks
like it's not just an issue in the JIT tiers, but it's also encoded in
the CFG phase as well.  Punting on that for now since it's not a refcounting issue.

A kind-of hacky way of identifying places that do unsafe (for refcounting)
setattrs.  When calling RewriterVar::setattr() with an owned reference,
you need to either promise to call refUsed() or refConsumed() afterwards.

we need this map to know which object refcounter we have to decrement in case an exception gets throwen inside an IC or the bjit.
in addition fix all bjit related problems

Any existing work on top of the unformatted branch might have a hard time
merging -- it should work ok to do a format on top of your changes and then
merge with this commit.

It returns an object that keeps the returned array alive.

saves a few bytes because r12 requires the SIB byte
django_template bjit bytes emitted shrinks from 3016247 to 3006353

We can't directly do OSR from the bjit frame because it will cause issues with exception handling.
Reason is that the bjit and the OSRed code share the same python frame and the way invokes are implemented in the
bjit. During unwinding we will see the OSR frame and will remove it and continue to unwind but the try catch
block inside ASTInterpreter::execJITedBlock will rethrow the exception which causes another frame deinit,
which is wrong because it already got removed.
Instead we return back to the interpreter loop with special value (osr_dummy_value) which will trigger the OSR from there.

Need to make setattr() stealing

We check for signals on most calls to runtime functions in the llvm tier and the bjit and inside the interpreter on some additional places,
because checking on every bytecode is a too large slowdown (>10%).

This removes the 2GB process limitation I ran into.
(With the EH frame format we are using the code offset is specified as a 32bit signed offset)
I checked if aligning the code speeds it up but I did not notice any perf change.

not sure about the code they emit though, since right now it's too large.

Current issue is that this is triggering the "mark IC as something
being inside", which trips up the bjit's "overwrite the last few
bytes of the previous block, assuming that they are just a jump".

LLVM tier: adjust num of IC slots depending on the num of times the IC got rewritten in the bjit tier

This commit works by adding a SmallFunction class that behaves
like std::function, but allocates its data inline rather than through
a separate allocation.  It probably could have also worked by taking
a custom allocator and using the new RegionAllocator.

It adds a bit more restrictions than std::function does (the types
caught by the closure have to be more "trivial" than std::function
supports), so some of this change is marking some types as trivial,
or copying data into a trivial format from things that aren't (ex SmallVector).

This removes a bottleneck of the interpreter/bjit:
most var accesses introduced a DenseMap lookup, with this change we use a fixed offset per var.
The bjit stores the pointer to the vregs array inside r14 for fast accesses.

This reduces the number of stack access, because previously when we accessed a field of the interpreter
we always had to load it first from stack into a reg - and now we have a dedicated reg.
This is currently only a very small perf change but when #736 lands this becomes more important.

Somewhat ad-hoc at the moment; only added for a few types
of operations.

this also adds support for calling 8 arg functions (=2 stack args)

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.

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.