Some functions are currently just stubs and I had to disable a
test which checked for a math exception because our C-API does
not support exceptions yet.
This is also yet another performance regression,
because patchpoint does not yet work for the C-API.

With these changes, the optparse test successfully runs!
It outputs a slightly different thing for us, since it
looks at the str of obj.__dict__, which for us is currently
an AttrWrapper.

I think this case is benign, so I'm hopeful that we'll be able
to keep __dict__ as an AttrWrapper and not as a full dict
(which would require deoptimizing that object and/or tracking
the existence of that dict to see if we can reoptimize).
I'm not sure if we'll be able to, but there's only one way to find out.

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!