For those calls (such as in conditionals and "not x" expressions),
if for some reason we didn't think the object could be converted to bool,
we would crash in codegen.  This could happen if we knew that the type was a
builtin type (ex: None, or dict) and we hadn't yet implemented __nonzero__.

Unrelated, but implement isinstance(obj, (tuple_of_classes,)).  This also
lets us use multiple exception types in a single except statement.

I'm not sure I like the current approach, but it seems to be working.

I didn't realize that pymem.h defined it originally to be malloc(),
which was messing things up when we would start allocating GC objects
using malloc().

Now that that's redefined, I *think* that as long as everything uses the
API functions, we shouldn't need to override / hook malloc().
There are a number of uses of raw malloc() in the Modules directory;
I hope that they're mostly string-related.

ie if you just have a __getitem__ method, you are still iterable.

This patch is unfortunately yet another performance regression, since
we obscure the behavior for known types (ie no longer try to go directly
to the __iter__).  Should make this into a call into type-specific behavior,
so that known types can use __iter__ if they have one?

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.