Generators

Previously, we just included a char[] buffer in the generator object,
and used that as the stack.

Now, mmap() a dedicated stack segment for it.  Use MAP_GROWSDOWN so that
the stack is automatically expandable, but add a redzone 4MB down to
limit the maximum stack size.

Turning off frame introspection can make things easier to
debug, but will break features like tracebacks.

If we turn it off, instead of trying to collect a traceback and
crashing, just print out a warning and return an empty traceback.

Previously it was pretty implicit where we rely on the fact that the generator
object will exist on the previous stack, and once we notice the generator
its GC handler will crawl the generator stack.

I think we also missed the generator's registers, but only the top generator
and only if it wasn't the current thread (was unable to reproduce this).

Now, keep explicit track of all the previous stacks that a thread had been on.
This cleans that up, and since things are explicit now, we can also track
where we stopped executing on each stack.  We were doing this hackily for the main
stack before, but now we can do that for generator stacks, which will let
us make those auto-growing as well.

My confidence in this change: low.

add doxygen

implement viewkeys viewvalues viewitems method on dict object

Need to 1) show that a thread is waiting, and 2) signal once
we've acquired the GIL.  Basically, what happens in acquireGL().

I feel like this isn't the sort of threading code that should
be written by hand...

Previously, to allow other threads to acquire the GIL, we would
just do a "releaseGIL(); acquireGIL();" and hope that another thread
would grab it.  The current thread has the best chance of grabbing the
GIL again, so I think what's been happening is that it would tend to
win the race to reacquire and starve all the other threads.

Now, the current thread is forced to wait for at least one other
thread to acquire the GIL before it can reaquire it.  This means that
we're at least fair between two threads, though not necessarily fair
between more than that (but at least it's more random and not as stacked
towards being unfair).

(update copyright notices)

I'm only seeing "undefined reference to ..." errors in the CMake
build on a specific machine; I'm not sure why they're only cropping
up in that scenario.

I think these functions are only referenced from dead functions,
and in other environments the chains get dead-stripped.

(We weren't including all of them)

Our previous directory names:
include/
lib_python/2.7/
lib_python/2.7_Modules/
lib_python/2.7_Objects/
lib_python/2.7_Python/

new directory names:
from_cpython/Include/
from_cpython/Lib/
from_cpython/Modules/
from_cpython/Objects/
from_cpython/Python/

Sorry for the huge diff, but I think this makes way more sense.

Was using the 'n' format character which expects a Py_ssize_t*, but was passing an int*.
Switch to using the 'i' character.

Add a Gitter chat badge to README.md

Cmake small updates to match Makefile

Previously we were compiling against the system headers, and then
linking against a different libstdc++.  Fixes #252.

Also, move the gtest install section into the "required dependencies"
section since you need it to pass "make check".

Trying to fix Issue #171