Haven't been able to test them all extensively but I tried
to only pick things refcount-related.

Another run-arbitrary-code-during-unwinding issue

The part that tests that certain dicts compare a given way.  We don't
have consistent dict comparisons yet (#1135)

Since the unwinder now supports throwing exceptions inside destructors (as long
as they don't propagate out).

This is the same change that C++17 makes, from "bool uncaught_exception()" to
"int uncaught_exceptions()".

This time it was from trying to look at the result of isUnwinding()
to determine if the function terminated successfully or via an exception.
(And in the exception case, to decref some values that would have been returned.)

This got tripped up in a case where we through an exception, this triggers
an AUTO_DECREF which takes an object to zero decrefs, which has a custom destructor,
and calls code that ends up calling isUnwinding().  This is all happening from inside
a C++ destructor, so this counts as isUnwinding().

We had some code to try to keep isUnwinding() meaning what we wanted to use it for,
but it was only for certain cases.  I think we might be able to extend it to more cases,
but it seems like that would be a losing battle since it's hard to say when "unwinding"
ends and then we are suddenly not unwinding.

So instead, I just disabled isUnwinding() (except in debug mode where it can be somewhat
useful for writing "assert(foo || isUnwinding())"), and then used a different way to
try to determine if the function exited normally.

bitset begin() function fix

refcounting fixes for numpy in PyTuple_GetSlice, PyErr_SetExcInfo and PyErr_GetExcInfo

Fix test_set.py

It fetches a webpage from a third-party server ("example.com")
and verifies the return code.  For some reason it's failing,
both for us and for CPython.

This time it was if __eq__ throws.

It was failing on master due to some of the test cases checking for immediate destruction.

Marius fixed the propagate-C++-exception case, and this commit
adds the to- and from-CAPI cases as well.

We were missing a guard and we ended up calling the wrong function :/

Still some other issuse with this test

Fix the lost-ref-from-oargs issue

They were both failing on master:
- test_dumbdbm was failing in a test case that writes out some data to a database,
  closes it, then reopens the db and expects to be able to read the data.
- test_memoryview expected some weakrefs to get cleared at the right time.

test_socket.py appears to "pass" -- it exits with code 0, but it spams a bunch of
error messages from other threads.

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.