This is so that we can add the CAPI slots for things like tp_as_sequence,
so that C extensions will work properly.

I don't think there are very many extensions that would do this but let's
still support it for now; it further bloats the type objects but only as
much as it does in CPython as well.

Previously had hardcoded three different iterations.

- Start moving towards slotdefs
- add tp_repr support
- add an slots_tester extension module so we can test these more narrowly

Move some type-related stuff into typeobject.cpp or descrobject.cpp

Separated out from some more involved changes that are
required to get the 'pwd' module working.

Haven't added structseq.c to the build quite yet

Remove some definitions that should no longer be in there
(structs for which we have Pyston-internal definitions).

Instead of doing "typedef void PyIntObject", do
"struct _PyIntObject; typedef struct _PyIntObject PyIntObject;"
which prevents spurious things like type conversions or
sizeof(void)'s.

I'm not sure that we need to do this at the expression-level --
I think we just have to do it at the statement level.

ie 'from a import b' now attempts an 'import a.b' if b does not already exist.
This also works for imports caused by__all__.

Previously we were calling it just 'b'.

ScopeInfo involves checking the whole function subtree to resolve
scoping references.  SourceInfo has information about the specific
function.  is_generator used to be in ScopeInfo, but accessing it
would require doing the full subtree analysis, which can be
unnecessary.

This lets us avoid analyzing function subtrees that are never entered.

With some changes
- renamed AST_Exec::expr -> body (to match CPython)
- removed references to AST_SetComp

add two passes which remove unnecessary boxing

* the first one removes boxInt, boxFloat and boxBool calls where the argument is coming from a corresponding unbox call
* the second pass removes duplicate boxing calls inside the same BB

together they improve the performance by about 10%

If we had to guard on the type of an object but the variable
ended up being undefined, we treated that as a guard failure
(not sure why).

Fixing that exposed another issue: if we guard that an object
is an int, we will try to unbox it if necessary.  If the variable
wasn't defined, then we will try to unbox some garbage memory.
Use the new handlePotentiallyUndefined to deal with that.