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.

One of them was an issue of defining a CXX-style accelerator but
not a CAPI-style one, so that's now asserted against.

Copy over tp_new_wrapper, which is the main thing that should be doing the check.
Our implementation was pretty much the same minus that check.

There's also a separate check that isn't completely necessary but seems like a good idea,
and we had it on certain codepaths, and whether you hit it depended on whether you were
in CAPI mode or not.

It will end up spitting out something like:

%x = callattrCapi()
Py_XDECREF(x)
if (!x) throwCapiException()

We usually write something more like:

%x = callattrCapi()
if (!x) throwCapiException()
Py_DECREF(x)

But with optimizations turned on, llvm will turn them into
the same thing.

We would incref them before putting them into the args array.
Now we keep some extra information during the rewriting process, which
lets rearrangeArguments say whether any of the values need to
be decreffed.  It's pretty rare that they need to so I think this
should be some nice savings (20% on a specifically-targeted microbenchmark,
no change on raytrace.py).

I'm a little bit worried though that since it is so rare to need to do the
decref, it would be easy to forget to check for it.

Well I think we already were forgetting it in some places... but at least now
it's an explicit arg you have to manage so maybe it's less likely to cause mistakes.