Conflicts:
	src/runtime/float.cpp

add refcounting annotation that make test_long pass

And also label the ones that are failing due to generator abandonment

I wasn't sure what we would have to do in this case --
we don't really have any way of cleaning up the data referenced
by those other threads.

Fortunately(?), CPython doesn't do much cleanup of those threads
(cleans up their metadata but doesn't try to clean up any references
held by the thread), so we don't have to do much either.  Just set
a flag saying that this happened and that we should skip asserting
that we got down to 0 refs.

Our underlying implementation still looks pretty different, but
rather than implement some newly-needed APIs completely from scratch,
I copied in some of CPython's implementation.

The result is a bit messy (multiple ways of doing similar things),
but I think it's a step in the right direction.

Regardless, this commit adds "clean up thread-local storage when the
local object dies" functionality, as well as better cleanup when
there are multiple threads.  I think this should help with the fork
issues as well.

Or rather, add some more refcount-related calls to it to help
it get down to zero refs at the end.

Ref nexedi fixing

I don't quite remember this but I think the goal was to ignore core/from_llvm, not all of core/

I think this adds some pretty heavy debugging that we might not always want,
but turning this on is always my first debugging step.

instead of using a hardcoded version.

This is important since we have some "#ifndef NDEBUG" conditionals in our include
files, and we would always compile shared modules in release mode (hence pyston
and extension modules would get compiled with different options).  Now, a debug
build of pyston will build extensions in debug mode.

To silence results for passing tests.  We have a lot of
tests and most of them are passing and are crowding out the
failing ones.

Also, turn it on when testing on travis-ci

Since we have a dedicated dict_comparisons.py test for tracking that issue

I think this ends up not affecting the interpreter because the interpreter
frame (that spawns the thread) ends up keeping the args alive for long enough?

It was just an error-message difference.

I guess it's good that we have that since it was firing to tell us
that we were generating bad assembly.

Will take some more work to actually free thread-locals since we don't expose that
I'm surprised we didn't actually free any of that before!

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