more getattr rewriting

Class gc fix: integrate with the finalization logic

I was noticing that classes were getting freed a few
collections after they were seen to be not-marked; the
issue with the old keep-classes-alive implementation is
that it assumed that !isMarked() implies that the object
will be freed in the sweep phase.  With the finalization
ordering, this isn't true.  We could move the ordering
before the keep-classes-alive behavior, but then the
finalization ordering might get things wrong since it
wouldn't see the final set of mark bits.  So I think
we need to integrate the two phases.

I think it ends up working to just say that type objects
have ordered finalizers, even though they typically don't;
I think this gets us the guarantees we need.

Fix and reenable type speculations

we were checking if the functions retrieves the exact same number of args as our calling convention requested this failed for varargs.
I encountered this while running test/cpython/test_math.py

travis-ci encountered sometimes a crash while running test_math.py.
This should fix the issue (the routines are used when creating a float from a string constant)

By moving the deopt logic into an inner frame.  I think we trigger
the isDeopt() block twice since there's a destructor that has to
get run.

Reduce some codegen allocations

Don't malloc-allocate rewriter lambdas

This commit works by adding a SmallFunction class that behaves
like std::function, but allocates its data inline rather than through
a separate allocation.  It probably could have also worked by taking
a custom allocator and using the new RegionAllocator.

It adds a bit more restrictions than std::function does (the types
caught by the closure have to be more "trivial" than std::function
supports), so some of this change is marking some types as trivial,
or copying data into a trivial format from things that aren't (ex SmallVector).

We were storing and passing them as std::unordered_map (and sometimes
switching to std::vector).  But the set can only contain the integers
0 through 15, so just represent it as a bitset.

Maybe a better overall approach is to not convert it out of its
original flat format; we keep that original memory around anyway
and I don't think it's that much faster to scan than our parsed
version.

But for now, optimize the current approach:
- convert vector->SmallVector
- call ensure since we usually know how many elements the vectors will have
- use a StringMap instead of an unordered_map<std::string>

ie a simple bump-pointer allocator that will release all
of its memory when the rewrite itself gets deallocated.

Not a huge help itself, since most of the mallocs have been removed
from the rewriter, except for the std::functions which don't take
a custom allocator (at least not in libstdc++ 4.8 [and 4.9 I think]).

Fix submodules

Somehow most of them did not make it in the second merge.

Undo testsuite split

Reduce allocations

Use adjustment-post division to avoid int division overflow

For some reason CPython allocates an extra "item" for generic
variable-sized objects, but it looks like it doesn't do that for
tuples.  We had been doing that, so let's try not doing that
and saving 8 bytes per tuple.

Reduces boxing during the import process

This is a temporary fix for the fact that "-1" is currently getting
parsed as "-(1)", which will cause us to call '(1).__neg__()' with
the associated overhead and allocation.

It should be useful even after that gets fixed though.

- Check for the allocation of empty tuples and just return the singleton
- Try to avoid creating the kwargs dict since it might end up being empty
- Let unicode-creation special case apply to all argument types
- Fix type(obj) to be fast again (got superceded by a different special case)
- Do fewer allocations in int()

Forgot to do this when I switched away from an StlCompatAllocator,
so we were leaking memory pretty badly.

more small exceptions optimizations

Actually, for now in all cases unless __init__ is a Python function.

- Add a has_subclasscheck class slot
- Add a fast path for when the exception matches exactly (though
  we have to check that there isn't a metaclass involved first).

The rest of our builtin types use our "hc attrs" (hidden-class-based attribute
storage), but we use the CPython implementation of exceptions which ask for
dict attributes.  So, expose our hcattrs via the C API and change the exceptions
classes to use it.

Hopefully we can eventually find some more general way of providing this feature
(ex for all string-keyed dicts) without needing these changes.