TODO: When using {} to construct the dict, contains works. However
if the dict type is used, the runtime crashes in various ways (see
tests/dict_contains.py)

This commit is a straightforward implementation that doesn't include
any speculation-like optimizations.  For operations that can overflow,
just relax the type-return-specification to UNKNOWN, and do the overflow
checks in the runtime.  This means that we no longer emit fast native
integer instructions even if we know operands are ints.

Will have to add optimizations:
- range analysis so that we can know there won't be overflow
- deopt-on-overflow so that we can work with unboxed ints even if there's potential overflow

Augassigns and for loops had an issue where they would try to
do something like 'i = i.__iadd__(j)', ie have multiple operations
in a single statement.  If an exception occurs, it's not clear if
the name got redefined; so far we just assume that it always does (since
we don't have the mechanism to propagate the name along only one
control flow edge).

So we have to split up those multi-operation-statements into multiple
statements.

Fix crash when passing alot of defaults

Implement Python Generators

Conflicts:
	src/codegen/compvars.h
	src/codegen/runtime_hooks.h
	src/runtime/objmodel.h

Just do it by putting a different class object on the same C-level structure.
Not too hard right now to defeat the frozen-ness, please don't try.

Ended up not being too bad, except for some more fun around classdefs
having different rules, and making sure to generate the correct error
type and messages.

Not worth producing CPython's error messages exactly: some delattr
messages depend on whether or not the object has a __dict__ allocated
or not.  Just canonicalize those in the tester.

Merges #101

Conflicts:
	src/codegen/runtime_hooks.h

Conflicts:
	src/codegen/runtime_hooks.h
	src/runtime/builtin_modules/builtins.cpp

Just convert them to ints and strings, failing if the conversion isn't possible.
Unicode and str are the same thing, right? :/

Conflicts:
	src/codegen/irgen/irgenerator.cpp
	src/codegen/runtime_hooks.h

Oh, no this was the issue: we were writing out valid-looking but corrupt pyc files if the parser crashed.  Now leave the files as corrupt if the parser crashes

Before was throwing AttributeError, since we were just translating it to:
import a
b = a.b

Now there's a special importFrom runtime function that does essentially
the same thing, but throws the proper exception.

Now more resilient to truncated pyc files; got into a bad situation
where the parser crashed, wrote out a half-pyc file, which wasn't
judged to be invalid.

Previously, a non-satisfied except filter would cause the traceback
to be lost, since we were using the one-argument 'raise exc' form.

For os.py.  Currently just do it by inspecting the set of modules
at the end of the runtime setup; CPython does it by examining the
"import inittab".

Required adding str comparison methods so they can be sorted.

bonus: add errno module.

The python stdlib apparently uses a bunch of old-style ways
of doing things.

Instead of doing the throwing directly in the generated IR, call
a runtime function raise1 which will take care of the semantics
of checking the type of the raised object, etc.