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.

Represent decref/xdecref operations as opaque functions calls.
I think the ideal solution would be to add a custom llvm intrinsic,
but I spent a small amount of time looking into that and had trouble
figuring out how to do that.

So instead, just emit them as patchpoints, and then patch them afterwards
with a fixed code sequence.

This commit only does this for decref/xdecref because:
- they occur much more frequently
- they are much more expensive to jit since they involve control flow
- forcing the op to fit a C-calling-convention isn't that much overhead,
  since the register allocator probably would have done that anyway due
  to the (potential) dealloc call.

I copied subtype_traverse and subtype_clear from cpython but
didn't update them to support our hcattrs

- fix instruction encoding of: add imm, mem
- fix Py_REF_DEBUG when increfing multiple times at once
- add missing bjit annotations

small refcounting fixing in tuple

I think they were timing out before

For use on the exception path.  Rather than emitting the instructions
for a bunch of decrefs, instead just emit a single call to xdecrefAll()

Improves performance quite a lot: sre_parse_parse llvm instructions goes
from 360k to 80k, and it's 60k if I manually disable cxx fixups.
Overall time [which is entirely compile time] goes from 12.5s to 4.4s,
though master does it in 1.3s so there's still some work to do.  But
even if I turn off cxx fixups entirely it still takes 2.9s.

fixups aka the stubs that decref whatever's needed when an exception is thrown

I looked into this because most (75%?) of the refcounting overhead
comes from the cxx fixups.  Previously we would always generate them in
the IRGenerator, regardless of whether they were needed.  Now they are
generated in the refcounter, which knows whether they are needed or not.

Unfortunately it looks like they are usually needed, so the gains here
aren't that great (saves about 10% llvm instructions whereas cxx fixups
in general added about 400% more llvm instructions).

I think this is still a good change because it's also necessary in order to use
Marius's EH stuff.

I think the cost of the fixups is mostly related to the cost of the decrefs
that it adds, so even though most of the refcounting overhead seems to be due to
adding the cxx fixups, reducing general decref overhead might reduce cxx fixup overhead

Any existing work on top of the unformatted branch might have a hard time
merging -- it should work ok to do a format on top of your changes and then
merge with this commit.

I think this exists on master as well.

Two minor refcounting fixing in int and long functions.

this is nice for making the generated LLVM IR and bjit code simpler when debugging code

Name deleting stores a NULL into the vregs array, and then
consumes a reference to it.  Another solution would be to change
the name deleting to not consume the reference, but this commit
changes the refcounter to handle null values better.

I thought I was getting close so I spent a few days on this.
But there's still a lot of work left to be done to get it to be usable.

Just pass a increfed None in becasue the LLVM tier will always decref this value

Previously we would check signals first.  Which means that we would then
call into a signal handler with an active exception, which would later
trigger asserts.

For CXX functions, the exception automatically wins over the signal checking.
CPython also checks signals first.

The only tricky thing is that this was happening because the signals stuff
was hooked deeper down the stack.  So pass down the CAPI-exception data as well.