split internal method calling helper functions into specialised 0-, 1-, 2- args versions to apply the method call optimisation to them

move increfs closer to the corresponding variable usages in C code (just in case it helps the C compiler to generate better code)

--HG--
extra : amend_source : 93bba856cb71e61c56335b3687337f5c68b62f2c

exclude types from method call optimisation again (thinko: we're dealing with the actual types here, not with their attributes)

exclude local Python classes from method call optimisation (even with metaclasses in place, they are fairly unlikely to return methods)

unbound methods/classmethods use PyMethodObject in Py3 as well, so include them in method call optimisation

If cppclass is redefined, make sure the this pointer enters the correct scope

fix test: passing an object into a METH_O Python function no longer stores it in a tuple and thus no longer increases its refcount

fine tune method call optimisation to mark likely plain function calls explicitly as unlikely() for the C compiler

enable method call optimisation on all simple Python calls as PyMethod_Check() should be cheap enough

avoid performance regression in one-arg calling case if the function turns out to be not a method at runtime

streamline method call optimisation a bit more by freeing method object as early as possible to put it back into CPython's freelist for quick reuse

The previous commit reveals too much information about the system.  With
this change only modules of the processed package are expanded.  The
expanded path reaches no deeper than the package's root.

The table of file names written to the c or cpp file contains absolute
file paths.  This affects, in particular, profiling.  The c method
__pyx_TraceCall takes as one of its arguments a file name, which will be
read from the table of file names.

replace PyMapping_Keys() usage by safer code (PyMapping_Keys() may return a tuple, but we try to sort it as a list afterwards)