ie if we do set.remove(k), we don't decrement k -- we decrement
whatever was in the set, which can be different.

We can just use the CPython implementation now

This is kind of dumb but it's the same thing that we were doing
with a tracing GC.

The unbound-instancemethod part of it is still failing, but I don't
want to gate the rest of the test on a failure that is unrelated.

ie calling an unbound instancemethod of the wrong type will result in an exception.
Tricky because this shouldn't end up applying to __new__

Where we hadn't gone through and updated the exception-catch
sites to clear/hand off their owned ref appropriately.

Mostly, what happens if class-creation fails.

add refcounting annotation to some set function

ie something like "print C().__dict__"

The attrwrapper objects don't (arnd probably shouldn't) keep their underlying
objects alive.  Previous to this commit they would just try to access their
freed underlying object and crash.

With this commit, object deallocation will check if there is an attrwrapper,
and if so convert it to be privately-backed.

First, our implementation of slot_tp_del (what calls Python-level __del__ methods)
was pretty bad -- it didn't re-incref the object to keep it alive.

Then we had some issues around running destructors at shutdown.  I made this section
look a bit more like CPython's, but there are still differences.

int positive function refcounting fixing

add refcouting annotation to zip builtin function

ie relax an assertion that doesn't quite check enough anyway.