fixed object.__new__ error message for >=2.7.4

fixed a number of small things to get it to work.

Also, updated most of the abort()-ing functions to print out a
Python-level stacktrace before actually calling abort() --
hopefully that won't cause any issues.

I guess our goal should be to eventually get rid of this directory -- this stuff
should mostly be just taken from CPython, and we could/should use their directory
names for that.  But for now it feels better than putting it all into a single file.

Working towards getting _sre.c to link (it compiles with the previous include/ additions)

Conflicts:
	src/runtime/objmodel.cpp

Even with some optimizations it seems to hurt perf a little bit...
we'll have to see if it's worth it.

Also, rename "static roots" to "permanent roots", since it's
slightly different than the "static allocation" problem we're
tackling here.

Add the sha256 and sha512 modules 

Using the C API it's possible to create a Box instance without using our GC alloc.
For example have a look at md5module.c: PyDict_SetItemString(d, "MD5Type", (PyObject *)&MD5type);

Add basic support for C API attr members

Works by using stack unwinding to find the most recent frame,
and then maps that back to the source information.
Soon we're going to need proper frame management (ex, this approach
does not work at for the locals() function), when this will be replaced.

globals() currently returns a non-dict... we'll see if that's ok.

Need this to track "softspace" correctly...

Before, the default behavior (falling back to __repr__ if __str__ doesn't
exist, and giving a default representation if __repr__ doesn't exist) was
provided by the repr() and str() functions.

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.