They do a refcount==1 optimization, where they mutate a tuple
if they see that it isn't shared.  I don't know if we can have
a good way of supporting this.

Maybe we can always tell extensions that refcounts are >1?  Not sure
if there's any macro magic we can do to make "obj->ob_refcnt" return
something of our choosing.

I think there are a couple ways we can go about this.  It looks like
extensions just specify tp_dictoffset if they want their instances
to have instance attributes, but don't usually actually look at the
dict or really make use of the fact that it's a real dict.  So possibly,
we have the ability to stuff a non-dict into the slot they reserved for
us.

Seems risky though.  Instead, the approach in this commit is to create
an actual dict and put it in like they expect.  All the attribute-accessing
paths have been updated to look at both the fast Pyston HCAttrs method, and
the CAPI dict method.

Apparently we can run quite well in the presence of GC bugs.
(We were scanning most extension objects using our Pyston scanner
instead of the conservative one.)  I am both relieved and terrified.

And now things work!

Use operator new() to get access to tp_alloc in a C++-ish way.

Instead of passing the object's class to the constructor, pass
it to new().  We need to do this since the class gets to pick how
the object gets allocated, including how large it will end up being.

Unfortunately it looks like defining an operator new on a subclass
hides the operator new from a superclass, even if they have different
signatures.  Macros to the rescue.

Add a PYSTON_NOEXCEPT define that gets defined to "noexcept" in C++ mode,
and to the empty string in C mode.

I don't think 'extern "C"' implies noexcept.

This is partly for better performance when we know that a function cannot throw
an exception, but also as an annotation for us since the exception model is
the main difference between C land and Pyston land.

Vim substitution: %s/\(\<PyAPI_FUNC\>(.*).*(\([^)]\|\n\)*)\);/\1 PYSTON_NOEXCEPT;/gc
- This will catch almost all cases, except for functions not marked with PyAPI_FUNC
  and function definitions that have extra paretheses (in comments, usually)

We're starting to have more functionality from CPython than we
wrote ourselves -- I think this is a good thing, but we should switch
Pyston code to calling it rather than supporting duplicates.

After I finish adding this stuff I'll try to clean things up a bit.

Most involved was the recursion checking stuff: switch to
providing the C API thread state rather than our internal
one, since they are mostly the same.

The recursion checking code doesn't mean much while most stuff
doesn't use it, but hey at least it's supported now.

Supposed to call type->tp_alloc(type) instead of PyObject_New

Adding Py_TPFLAGS_BASETYPE and checking it

And some install instructions on how to get a pre-built debug build,
and to put the sources where the Pyston make system expects them.

Add a hook to tell us what functions are taking a long time to JIT (spoiler: still sre_parse.py::_parse)

Special case {int,float,long}.__new__({int,float,str}) for
rewriting.

float.__new__(cls) can return something that is not an instance of cls

Disable rewriting of float.__new__ and int.__new__ in this changeset

If cls is int, and the argument has an __int__ method that returns
a subclass of int (that is not an int), then int.__new__ will return
that.

Will need to make the typeCall rewriting criteria tighter.