Previously we only supported one unwind to happen at a given time.
The change is unfortunately quit ugly :-( but should work.

Trying to reduce allocations in refcounting branch

Add some liveness information to the cfg

I had added an allocation to deal with the requirements refcounting
added.  To remove that allocation, I added a "SmallUniquePtr" class
which is similar to unique_ptr but it allocates the object in-line.

It's a bit tricky to use since if the containing object gets moved around
then the pointers become invalid.

Previously, to replace a refcounted object in memory, we would do something like

array->getAttr(offset)->setType(OWNED);
array->setAttr(offset, new_val);

The problem is that this ends up emitting something like
x = array[offset];
Py_DECREF(x);
array[offset] = new_val;

which is not safe, since x can have a destructor that runs.
In this particular case, the destructor changed the value of array[offset].

It's actually pretty hard to get the right behavior (decref after setting the
new value) from outside the rewriter class, so add a new replaceAttr that does
these steps.

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.

Fix another raise-before-stealing-argument bug

Fix the test_string segfault error

Misc refcounting leaks encountered while fixing the generator abandonment tests part 2

this get all triggered by cpythons test_set.py
the problem is mostly that BoxAndHash(Box*) can throw

fix bjit crash with large dicts

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.

Fix + reenable the bjit

- I think I've finally convinced myself that a refConsumed() annotation
  automatically includes a refUsed annotation as well.  Or rather, that if you
  call refConsumed, the refcounter won't try to add a decref anyway.
- emitCallWithAllocatedArgs already does the equivalent of refUsed() on its `additional_uses`
  argument.

fix set.add() for existing keys and fix set ast node when encountering keys with same hashes

we have to insert the elements in reverse in order to replicate cpythons behaviour.
cpython is pushing the temps on it's value stack and than inserting them ona after another by poping them from the stack

I think I don't quite understand the existing optimization so just
turn my new one off for now.

Also fix the is_live handling and make the get and set
cases look more similar to each other.

Our convention is that on deopt, the callee is responsible for calling deinitFrame().
This is tricky, since for OSR our convention is the opposite, that the caller calls deinitFrame().

This means that if we OSR and then deopt(), the top and bottom frames both think they should call
deinitFrame() (since one is the caller of an OSR and the other is the callee of a deopt).

This commit fixes + extends the "disable deinitFrame for this frame" approach we kind of had.
For performance, deinitFrame() stays the same, but any site that might have its deinitFrame disabled
(namely, in the interpreter), it should call deinitFrameMaybe() instead.

They might be ok if we allowed allocating callee-save registers, but
since we don't, they mean we are asking the unwinder to restore a
clobbered register.

This was happening in some places where we didn't call setupCall()
before calling a function.  This was previously ok since those cases would
always throw an exception and nothing would want the values of the
then-clobbered registers.

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.

Need a 'refUsed()' function like we have in the llvm jit, for when we pass args
through an args array.

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

Misc refcounting leaks encountered while fixing the generator abandonment tests