Not sure if it's better or not to have the "unicode"
name accessible, given that we don't support much
of its functionality at all.

For instance, sre_compile detects if "unicode" is available,
and if so, calls `type(unicode(""))` which will fail for us.

Conflicts:
	src/runtime/types.cpp

random_test.py is running into the same issue as _random_test2.py,
of the rewrites failing.  Will deal with that next.

Fix a memory corruption in posix.urandom

this let's us import random

In addition fix a valgrind uninitialized memory use warning
and close the opened file descriptor in posix.urandom

Has been failing with weird segfaults; hunting them down

Had to merge in some recent changes
- compileAndRunModule -> createAndRunModule
- new "allow-warning" directive syntax in tests

Also had to fix some bugs with codegen function types --
not sure how those snuck through

It doesn't create a new module at all -- it directly uses the existing one.

Fixing that let us clean up some of the module handling code.

Caught a couple benign places and one potentially-real issue.

Also fix a bug where we were rewriting all member descriptors
as OBJECT types (ie just load the offset), which is what was making
hashlib crash (the first thing that uses non-OBJECT member types).

(as long as you get a pointer to it in the right way)

1-arg version of exception constructors
str*bool -- who would have thought

- was missing comparison methods on 'long', and we were happily using the default comparison rules
- isinstance for oldstyle classes
- int * str (who does it that direction??)

Performance is abyssmal: 2s for us vs 30ms for CPython

In theory it's simple: we just run cheaper type analysis on lower tiers.
In practice it's more complicated, since the different tiers have to
cooperate on the types that they send back and forth.

I fixed up some of the code that didn't expect to receive a type worse
than what it knows to be true.  Ran into an issue where we have to
treat potentially-undefined symbols specially, since we can't do a class
check on them because they probably point to garbage.

Stopped there for now, since this section of the code is horrible and we
need to rewrite the tiering framework anyway.

- Use the right unpacking protocol (ie don't check __len__, just try to iterate)
- Handle unpacking exceptions appropriately
- Expand the targets of assigns correctly (think: f().x = 1)
-- this was not just for tuples but came up here first; this also was broken:
[0 for i in xrange(5)][0] = 1
(silly but legal)

fixed exception bases and added a few exception classes

Not going to be very performant -- hopefully that won't matter.

basestring

Complex2

The mechanics for creating one actually seem pretty simple:
you just pick a different metaclass (ClassType).

I think the old-style classes are working ok now, but the old-style
instances very much are not.

We actually had most of the base support in place; this commit just adds
the ability to specify a metaclass other than type_cls, and the ability
to determine which metaclass to use when defining a new class.

But just like how we have the base functionality to inherit from all the
builtin types but haven't updated all the functions yet, I bet there
are more places that assume the type of a class is always type_cls.

Somewhat confusing, since us_compiling_analysis_liveness is
also contained in us_compiling_irgen, and I'm not sure of a good
way to avoid that for now.

But anyway, for "import re", the breakdown is roughly:
- 215ms definedness analysis
- 50ms liveness analysis
- 80ms phi analysis
- 200ms type analysis
- 5ms irgen
- 25ms other compilation stuff
- 40ms non-compilation time