use it for attrwrapper_cls (This gets also often called for real dicts but the implement the mapping already)

This is an optimization but also fixes an lxml issue:
it calls AttrWrapper::getitem even though an error is currenly set. (which would assert if we do a callFunc call for the getitem)

Fix repr() of oldstyle class infinite recursion. add _PyErr_BadInternalCall and PyCFunction_GetFlags

before it produced the following exception:
TypeError: unicode() got multiple values for keyword argument 'encoding'

Copy in the rest of CPython's tests

Some xrange improvments

Gc fix

Add missing tp_iter and tp_iternext functions

1) instead of hooking loadConst to automatically find GC references,
   add an API for specifically saying that a reference needs to be tracked
   (I think/hope there aren't more that do this)
2) change the way we store the gc references so that it's O(#references) to
   scan them instead of O(#ics).

I think this is actually pretty decent, as long as we don't
depend on the class's gc pointers being dereferenceable.
We could go back to having the finalization-ordering algorithm
handle this part, but it gets tricky when the class can refer
back to instances of itself (the situation that prompted this).

make more module test pass

Match cpython's HEAPTYPE flag

It's supposed to mean "whether this type is heap allocated", but
it gets used as "is this a builtin/extension type".  We heap-allocate
our builtin types so we were setting HEAPTYPE, but this keeps on
causing issues.  I don't think anything actually uses HEAPTYPE to mean
it's on the stack or heap, so let's just set them all to be HEAPTYPE=0.

For better or worse, I ended up implementing this by changing the builtin
types from BoxedHeapClasses to BoxedClasses, which seems to make sense.
This had the effect of changing the existence of the tp_as_foo structs,
which get automatically created for HeapClasses but not for non-heap classes.
So most of the changes in this commit are trying to make sure that we
have those when CPython has them.

Get more of the sqlalchemy tests working

so object's can be resurrected even with a non-resurrecting
tp_dealloc.  The only thing that can happen at that point is
that the gc_visit function will get called.

This shows up in the new sqlalchemy tests: they use a subclass
of dict (defaultdict), which defines a custom tp_dealloc.  We call that,
which ends up calling dict_cls->tp_dealloc, which calls ~DenseMap
on the internal DenseMap.  The GC will accidentally keep the object
alive (via a stack reference or something similar), and call its
visit function on the next GC.  But ~DenseMap does not leave the map
in a consistent state, so iterating over it will end up producing
garbage values.  To solve this, add a new function that does
all the same memory-freeing, but does a tiny bit of extra work to keep
the DenseMap in a valid state for future gc_visit calls.

More set stuff

__new__ is supposed to become a staticmethod

Enable the "mmap" module

symmetric_difference, in-place binops, etc

by expanding our test harness to be closer to how the tests get
run under pytest (which we don't support yet)

Also fix a couple minor things that this turned up.  There is a lot more
to be found here: the new harness supports many more of the sqlalchemy
tests, a number of which aren't working for us.  Also there is some
sort of issue with the current tests that we run, since repeating the tests
multiple times will end up crashing.

Signed-unsigned comparison giving bad results for the comparison.  Should probably
turn -Wsign-compare back on.

This seems to not matter very much, but it means that
Cls.__new__ is a the original function, instead of an
unbound instance method.

Fix set comparisons

Allow changing the number of default arguments

We already supported changing the values, but not the number
of them.  The main trickiness here is
- We had been assuming that the number of defaults was immutable,
  so I had to find the places that we used it and add invalidation.
- We assumed that all functions based on the same source function would
  have the same number of defaults.

For the first one, I found all the places that looked at the defaults array,
which should hopefully be all the places that need invalidation.

One tricky part is that we will embed the num_defaults data into code produced
by the LLVM tier, and we currently don't have any mechanism for invalidating
those functions.  This commit side-steps around that since the only functions that
we can inline are the builtins, and those you aren't allowed to change the defaults
anyway.  So I added a "can_change_defaults" flag.

For the second part, I moved "num_defaults" from the CLFunction (our "code" object)
to the BoxedFunction (our "function" object), and then changed the users to pull
it from there.