Fix usage of undef variables

I think I had gotten confused and mixed up "undefined variables" (Python
variables which hadn't gotten set) and "undefined values" (results of
expressions that the JIT knows will throw, or otherwise can't evaluate).

For undefined *variables*, we represent them using None, since they can
still have refcount operations done on them.

For undefined *values* (or results), we can use llvm's undefValues, since
they should never be touched.

Fix the last two reffail tests

At least what I added here is what CPython does.

But still some in test/integration

Undo a bunch of Pyston changes to cpython code

copy CPython sys.getsizeof implementation with some Pyston changes

Bitset iteration micro optimize

This just copy the CPython implementation, so some NumPy tests could pass.
But most of types in Pyston didn't implement '__sizeof__' attribute yet.

Haven't been able to test them all extensively but I tried
to only pick things refcount-related.

Another run-arbitrary-code-during-unwinding issue

The part that tests that certain dicts compare a given way.  We don't
have consistent dict comparisons yet (#1135)

Since the unwinder now supports throwing exceptions inside destructors (as long
as they don't propagate out).

This is the same change that C++17 makes, from "bool uncaught_exception()" to
"int uncaught_exceptions()".

This time it was from trying to look at the result of isUnwinding()
to determine if the function terminated successfully or via an exception.
(And in the exception case, to decref some values that would have been returned.)

This got tripped up in a case where we through an exception, this triggers
an AUTO_DECREF which takes an object to zero decrefs, which has a custom destructor,
and calls code that ends up calling isUnwinding().  This is all happening from inside
a C++ destructor, so this counts as isUnwinding().

We had some code to try to keep isUnwinding() meaning what we wanted to use it for,
but it was only for certain cases.  I think we might be able to extend it to more cases,
but it seems like that would be a losing battle since it's hard to say when "unwinding"
ends and then we are suddenly not unwinding.

So instead, I just disabled isUnwinding() (except in debug mode where it can be somewhat
useful for writing "assert(foo || isUnwinding())"), and then used a different way to
try to determine if the function exited normally.

bitset begin() function fix

refcounting fixes for numpy in PyTuple_GetSlice, PyErr_SetExcInfo and PyErr_GetExcInfo

Fix test_set.py

It fetches a webpage from a third-party server ("example.com")
and verifies the return code.  For some reason it's failing,
both for us and for CPython.

This time it was if __eq__ throws.

It was failing on master due to some of the test cases checking for immediate destruction.

Marius fixed the propagate-C++-exception case, and this commit
adds the to- and from-CAPI cases as well.

We were missing a guard and we ended up calling the wrong function :/

Still some other issuse with this test

Fix the lost-ref-from-oargs issue

They were both failing on master:
- test_dumbdbm was failing in a test case that writes out some data to a database,
  closes it, then reopens the db and expects to be able to read the data.
- test_memoryview expected some weakrefs to get cleared at the right time.

test_socket.py appears to "pass" -- it exits with code 0, but it spams a bunch of
error messages from other threads.

The Rewriter will automatically refcount objects represented as RewriterVar's,
but if you store one as an attribute somewhere, it can't keep track of that.
So add a registerOwnedAttribute() function that lets you say that there is
a reference that lives in an attribute (stored in a memory offset) of another RewriterVar.

Fix some pyexpat issues

bjit: directly emit recordType again

the comment was totaly not true, result can't be 0 for our uses

cleanup abandon generators

this makes sure that we don't generate additional cycles to the generator