The line of a decorated function is the decorator

This is the test for the fix in vinzenz/libpypa#49

fix Makefile to be able to 'make' after 'make clean'

Properly handle METH_COEXIST

By importing the cpython implementations of add_methods / add_members /
add_getset.

Set cls->has_getattribute for extension classes

Misc small fixes for lxml

this got introduced in c9598857 for getattr

this is how cpython does it.
The implementation of PyImport_ImportModule is still very different and I haven't verified it any further
but at least this now lets "from lxml import objectify" work (it internally imports "lxml.etree")

Also remove a few asserts when assembly generation failed
and teach type_analysis about None and while there cache the scope result.

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