fix two python frame handling crashes

I have been noticing quite some perf variance - hopefuly this makes perf more predicatable again.

We used to not detect deopt frames in release mode this was because we are looking for 'astInterpretDeopt'
in the call stack but this did not work because the compiler optimized this function to a jmp to astInterpretDeoptInner.

I tested different compiler attributes but I ended up implementing this small wrapper function in assembler
because I think it's the most reliable way to make sure it does appear in the call stack.

bjit: microptimization use r13 instead of r12 for the interpreter pointer

bjit: don't directly do a OSR from the bjit

saves a few bytes because r12 requires the SIB byte
django_template bjit bytes emitted shrinks from 3016247 to 3006353

We can't directly do OSR from the bjit frame because it will cause issues with exception handling.
Reason is that the bjit and the OSRed code share the same python frame and the way invokes are implemented in the
bjit. During unwinding we will see the OSR frame and will remove it and continue to unwind but the try catch
block inside ASTInterpreter::execJITedBlock will rethrow the exception which causes another frame deinit,
which is wrong because it already got removed.
Instead we return back to the interpreter loop with special value (osr_dummy_value) which will trigger the OSR from there.

check duplicate function params

implement correct binop lookup for subclasses

Threading and multiprocessing related fixes

if we get the attrwrapper of an object, then change it to be dict-backed,
the original attrwrapper should remain valid but no longer connected to that object.

this caused problems inside the multiprocessing module

add support for custom traceback entries

it only allows creating empty code objects but this is enough to allow ctypes and cython to create custom traceback entries.

It's not enough for removing the pyexpat and all cython code object workarounds (because they need 'real' code object / frames)

This makes it more similar to cpythons and without this PyTraceBack_Here does not work correctly.

add a paste, pylons and routes integration test

I encountered them when I disabled str.__iter__

fixes for CFFI and add an integration test for it

clang generates code which assumes that the PyCArgObject::value is 16 byte aligned but our current allocator only 8byte aligns
This made all code which used types crash on travis CI

We can now run most of the CFFI tests.
Some of the changes were required because CFFI tests loading the same shared library several times from different locations.

This also enables some ctypes tests (test_uuid was coied from the wrong cpython version)

Abstract class improvements

add parser module

main motivation for this is that old versions of pytest use this module
in additon enable some cpython test we pass and add all shared libraries we generate to CMakeList.txt

and add float() and str() param names
In addition noticed that we did not run one of our small numpy tests

This fixes infinite recursion bugs when C extensions inherit from
these built-in types where the C extension allocation function calls
the base tp_new, which does an attribute lookup, which finds the
C extension allocation function again.

Address minor comment from #1028

and add float() and str() param names
In addition noticed that we did not run one of our small numpy tests

Update copyright to 2016

Fixes for tp_new for C extensions

This makes the implementation more similar to cpythons and removes some missing error handling.
It also uses and implements some missing PyRun_* and PyEval_* functions.
One behaviour change is that 'execfile' now always uses the cpython parser.

If think if we want to support other parsers the right way would be to decide inside PyParser_ASTFromFile which parser to use.