I guess there's actually a real __future__ module that contains
information in it about the special features you just enabled!
Until this change you would get that information, but not actually
enable any features.  The right behavior is to raise a SyntaxError
for all __future__ directives we don't support (which is all of them).

"import __future__" works if you want that...

I'm not sure that throwing a SyntaxError from the IRGenerator is safe,
since there are things that won't get cleaned up, but I guess
it's not that much worse than if it worked; and this SyntaxError will
typically kill the program anyway.

(working on getting more of the stdlib to import)

Well not really, it crashes the GC by simply existing, but it's close!

ie trying to start running real C modules.  The goal has always been to
run them without modification and without a proxy layer, and this is the first step.

The first issue is conversion between PyObject and our internal representation,
"Box" (needs to be renamed).  Once they have the same layout, some hacks were
needed to make them seem like the same thing, even though we can attach C++
methods on the Box side, but use PyObject in C code.

The next major issue was PyTypeObject, since the structure is directly exposed to
extensions.  I just added the similar fields to BoxedClass, so they can be
used interchangeably; the "real" ones are the BoxedClass ones, but we'll migrate
them incrementally.

There's also the issue that PyTypeObject's are typically created statically,
so I added registerStaticRootMemory to the GC interface.

Also add in a smattering of other API functions, and the _sha module works
(who cares if it's normally disabled).

The C API is quite constraining about choices of data structure implementation; it's
in direct conflict with the std::string API, for example.  For now, close our eyes
and let the C API modify the internal bytes of std::string.

Added dict.__new__ accepting list/dict + tests

Fix negative indexing issue.

Also fixed __getitem__.  Previously was using ->[key] which
would place a NULL value for the key if the key didn't exist.
Subsequent calls could segfault.

Conflicts:
	src/runtime/tuple.cpp
	test/tests/tuples.py

Some tweaks to better support C (as opposed to C++) compilation.
Can now compile extension modules using gcc, in addition to clang as before.

Merges PR #109

Support added to initialize a tuple using the tuple type class.  Allows
creation specifying positional or using the keyword argument 'sequence'.

Accepts iterables- tested with lists, tuples, sets, dicts and strings

Need to special-case some places in the keyword handling
since they previously assumed that they would first have
to check if the keyword name matched a positional argument,
before putting into the output **kw.

errnomodule.c is extremely simple and doesn't do anything complicated,
so this is more of a proof-of-concept for now.
The tricky stuff will most likely be around newly-defined types.

The previous code assumed that there was only one stack per
thread, which could be examined by looking at the current registers.
Generators complicate that, since we switch to a separate stack.
We still need to scan the original, main stack, which means that
we need to add some bookkeeping code that remembers what the main
stack was, even as we swap to and from generators.

Nothing major was wrong, but was trying to double-pass the
generator/closure arguments.

Previously the gc header had to be set and managed by the user of the GC,
which didn't make much sense.

Also took this opportunity to clean up a bunch of old cruft.

Also got rid of ObjectFlavors and AllocationKinds, in preference for
a GCKind which I think makes more sense.  Right now there are only three
different GCKinds, but I'm not sure if the previous AllocationKinds
should each get their own GCKind.

Conflicts:
	src/runtime/str.cpp
	test/tests/str_manipulation.py

Added capitalize and title functions for strings

Implement tuple.__add__, dict.__contains__ and builtin id() function