- simple bug where when clearing the IC I forgot to clear
  the old list of gc references.
- keep gc references alive during the duration of the rewrite.
  There are some cases where the thing we are guarding on would
  normally get destroyed by the end of the operation.
  So make the ref an owned ref.  But at the end if we see
  that we hold the only reference to the object, abort the rewrite
  (since the guard could never pass in the future)

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.