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

Was not being careful about distinguishing starting states
vs ending states... I'm not sure why that worked at all.

Also include Marius's optimization from PR #137

This is currently only being used by the DefinednessAnalysis which
could probably have a much faster algorithm.

foundation for complex numbers

Import math module

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.

Also required adding some string functions so that
we could use os.path.

made __module__ a member descriptor for functions

Looks like we're going to be using much more CPython code than just
in lib_python, so call that out specifically in the main LICENSE file.

Conflicts:
	test/tests/dict.py

Conflicts:
	src/core/ast.cpp
	src/core/ast.h

Conflicts:
	test/tests/builtins.py

The benchmark runs but crashes due to OOM, I think because we
never release the underlying long memory (due to lack of finalizers)

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.