Split 2-tuple unpacking helper function into a (still) inlineable fast-path and a slow fallback function that does not need inlining.

Also avoid double-check overhead for strigns and string subtypes in Py2: only needed in Py2.6 and not really worth it.

Supply a general macro for fast exception setting without value (e.g. StopIteration).

Mark intended fall-through steps in switch statement of int-pow() implementation with "CYTHON_FALLTHROUGH" to avoid compiler warnings.

Avoid excessive inlining of __Pyx_GetBufferAndValidate() helper and only inline the initial None check through a macro.
Assumption is that explicit None assignments to buffer variables are somewhat common to clear data and NULL checks can be eliminated, but everything else takes substantial time anyway.

Switch setup.py script to calling cythonize() through "new_build_ext" to get a clean split between the "translate" and "compile" steps. Previously, it would alternate between the two, which meant that Cython was already partially compiled while it was still being used.

Attempt to use a faster exception value for return type annotations that check for exceptions

Prevent character escape sequences from being resolved in raw f-strings (fr"..."). Also fix some error reporting issues along the way.
Update test_fstring.py test file from Py3.7.

Disable Pythran integration testing in travis as it currently fails to compile with the latest release version of Pythran (changes pending on their side).

Avoid using PySequence_ITEM() on METH_O calls as it involves much more overhead than PyTuple_GET_ITEM().
Also assume that we do not need to keep an extra reference to an item that we took from a call args tuple because someone else should at least hold a reference to that tuple.

Clean up Pythran setup in cythonize() and make it a little more robust by also looking at the extension, in case it already has the "np_pythran" option set.

Inside of a module, it is safe to convert a function declared
    cdef int func() except *:
        ...

into

    cdef int func() except? -1

because a) we need an exception return value anyway and b) there will always be an explicit exception check afterwards. Thus, changing the function implementation itself is safe. We must exclude functions that are only declared but not implemented since we do not control their signature and it is not safe to assume a specific exception return value if it is not declared.

Implement a "--pgo" option for the Jupyter magic that applies profile guided optimisation during C compilation.