Added tuple.__new__ accepting an iterable + tests

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
Fix negative indexing issue.
Removed boxStrConstant, uncommented a few tests
Merge remote-tracking branch 'upstream/master' into runtime

Conflicts:
	src/runtime/tuple.cpp
	test/tests/tuples.py
Added dict.__new__ accepting list/dict + tests

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.
Merge pull request #125 from jvkersch/fix-tuple-indexing

Fix negative indexing issue.
Merge pull request #126 from chrisrammy/runtime_dict

Added dict.__new__ accepting list/dict + tests
Wow, I did not think that descriptors would apply here
Try to cut down the time of this test since it was sometimes timing out
Import some CPython header files, and start modifying for Pyston
Some work on the Grand CAPI Unification

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.
Import patchlevel.h
Apparently _md5 also works

Well not really, it crashes the GC by simply existing, but it's close!
Add BytesWarning, sys.platform, and sys.flags

(working on getting more of the stdlib to import)
Throw a SyntaxError if you try to import from __future__

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.
Add object.__str__ and object.__repr__

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.
Faithfully follow the Python 'print' protocol, at the cost of performance.

Need this to track "softspace" correctly...
Add support for the globals() builtin

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.
AttrWrapper.__contains__
Support for __get__ and __set__ for descriptors