ie a commit that worked around our (previous) lack of refcounting.

I think technically only the globals are needed but I think this is
probably safer.

There's a FunctionMetadata* inbetween that doesn't get memory managed,
so the function just looks through that for now.

Or maybe it's just hacking it up some more.

Not very realistic but easy for testing

Use the CPython technique of swapping out the list contents for
the duration of the sort, since the compare functions can look at
the list.

This wasn't even being triggered by something that explicitly looked
at the list: the issue was that the comparison function invoked a
gc collection and the gc saw the half-mutated list.

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