The Rewriter will automatically refcount objects represented as RewriterVar's,
but if you store one as an attribute somewhere, it can't keep track of that.
So add a registerOwnedAttribute() function that lets you say that there is
a reference that lives in an attribute (stored in a memory offset) of another RewriterVar.

Fix some pyexpat issues

bjit: directly emit recordType again

the comment was totaly not true, result can't be 0 for our uses

cleanup abandon generators

this makes sure that we don't generate additional cycles to the generator

we create quite strange lambda cfg nodes but it should be fine I guess

in order to break cycles we need to traverse all generator owned object at yields.
The interpreter is fine because it stores all objects inside the vregs so they will already get visited.
For the llvm jit pass all owned object to the yield call as vararg argument.

We will currently leak (move objects to gc.garbage) when a generator is involved in a cycle because our PyGen_NeedsFinalizing() is much more conservative.

the idea is that stealing the value allows us to immediately free the variable in more case when it's unused
otherwise we would always have to continue the generator in order to decrease the refcount

this can happend when a deopt() call inside the llvm tier throws.
We would catch the exception in order to do some decrefs and than reraise it from the disabled frame.

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

We were double-registering its exception type as a static constant.

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.