Avoid deprecation warning for "Py_UNICODE_strlen()" by always using the version that we ship anyway.

Improve C macro guard: __Pyx_GetAttr() should be optimised exactly iff __Pyx_PyObject_GetAttrStr() is also optimised.

Avoid inlining some generic fallback functions. However short they are, they are just fallbacks and shouldn't get in the way.

Refactor dependencies between buffer/memoryview utility code to avoid unused C code and remove explicit utility code dependency lists from Python code where possible since they are much better expressed right in the C code.

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.