It wasn't decreffing the previous value if there was one

well, ones that aren't quite constant.  They can just register
their C static variables and then change them at will.

The _warnings module does this

It's bad that we need to do that right now, but it's not the job of
these tests to test that.

- Some missing refcounting annotations
- We would allocate before guarding, so if the guards failed we would
  leak those objects.
  - The code now treats this conservatively (like it should), which
    might result in more rewriter aborts.  I manually tried to fix
    the case that was hitting this for now.
- Small bug in the llvm-tier type specialization

- 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__