Check for exceptions also when @returns() is used, not only for "->" return type annotations. (GH-3664)

When you use Python type annotations, it would be weird if you lost Python exception propagation semantics along the way, just by compiling the code. So the default behaviour is "except? -1" here for C integer types.

Arguably, this would also be a better default for the decorator case.

See https://github.com/cython/cython/issues/3625#issuecomment-631931675

Return statements inside of nested try-except statements lead to an incorrect control flow graph that did not take the outer 'finally' clauses into account.
Closes https://github.com/cython/cython/issues/3666

classmethod() should fall back to calling PyClassMethod_New() instead of deciding for itself that the type is invalid. (GH-3660)

Fixes https://github.com/cython/cython/issues/3642

Fixes https://github.com/cython/cython/issues/3642

Add "show_all_warnings" option to cythonize() to provide a simpler interface for (temporarily) setting "Errors.LEVEL".

See #3625.

Add a test that the default exception return value "-1" for integer return types also works for unsigned types.

Avoid "possible loss of data" warning in MSVC by adding redundant casts to code that gets discarded later.

Exclude "long long" overflow checking code from compilation when HAVE_LONG_LONG is not set by CPython.

classmethod() should fall back to calling PyClassMethod_New() instead of deciding for itself that the type is invalid. (GH-3660)

Closes #3659.

Fixes https://github.com/cython/cython/issues/3642

(Although that seems a bug – deep copying should probably just keep the control flow graph intact.)

Fix detection of reusable utility code: whenever we do string and/or unbound method replacements at all, it's not reusable.