This fixes a few issues in MemoryView_C.c to allow atomic reference
counting to be used in more cases.

 - Enable GNU atomics for `__GNUC__` >= 5. Previously, GCC 5.0, 6.0, X.0
   versions used lock-based reference counting due to an incorrect preprocessor check.

 - Typo in `__GNUC_PATCHLEVEL__` macro (missing underscores)

 - Enable atomics in MSVC and fix returned values. InterlockedExchangeAdd
   returns the *initial* value (like __sync_fetch_and_add).
   InterlockedIncrement returned the *resulting* value (post increment),
   which would have been incorrect if MSVC atomics had been enabled.

Also avoids allocating a lock in MemoryView when atomics are available,
which additionally fixes a thread-safety issue in the "nogil" CPython fork.

* Use _InterlockedExchangeAdd intrinsic

The InterlockedExchangeSubtract function isn't available in older
versions of MSVC, while InterlockedExchangeAdd is available since
Windows XP.

The intrinsic variant (with the underscore prefix) avoids needing to
include the entire Windows.h header.

* Only use MSVC atomics when compiling for the "nogil" CPython fork
  to prevent potential breakage of existing Windows setups.

See https://github.com/cython/cython/issues/4913

Also, pass "usedforsecurity=False" in Py3.9+ to unblock MD5 also on some security constrained systems (FIPS).

Closes https://github.com/cython/cython/issues/4909

CI: Remove "allow_failures" for Python 3.11 to make sure we notice failures during the release phases (GH-4780)

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

I don't believe it's easy to fix
https://github.com/cython/cython/issues/4798 on 0.29.x Therefore,
generate an error message that explains two possible workarounds.

This at least makes sure that people don't end up with mysterious crashes.

Follow up on https://github.com/cython/cython/pull/4859 by adding tests for memoryviews too.

Additional refactoring to avoid invalid decref calls on test failures. Instead, the item is safely cleared directly before the access.

This reverts commit 7c789034.

object means the argument is always non-NULL valid Python object, while
PyObject* argument can be generally NULL. If the argument is indeed
passed as NULL, and we declare it as object, generated code will crash
while trying to incref it.

Quoting https://github.com/cython/cython/issues/4822:

    object.pxd currently declares `newfunc` as follows:

    ```pyx
    ctypedef object (*newfunc)(cpython.type.type, object, object)  # (type, args, kwargs)
    ```

    which implies that `args` and `kwargs` are always live objects and cannot be NULL.

    However Python can, and does, call tp_new with either args=NULL, or kwargs=NULL or both. And in such cases this leads to segfault in automatically-generated __Pyx_INCREF for args or kw.

    The fix is to change `object` to `PyObject*` for both args and kwargs.

    Please see below for details:

    ```cython
    # cython: language_level=3
    from cpython cimport newfunc, type as cpytype, Py_TYPE

    cdef class X:
        cdef int i
        def __init__(self, i):
            self.i = i
        def __repr__(self):
            return 'X(%d)' % self.i

    cdef newfunc _orig_tp_new = Py_TYPE(X(0)).tp_new

    cdef object _trace_tp_new(cpytype cls, object args, object kw):
        print('_trace_tp_new', cls, args, kw)
        return _orig_tp_new(cls, args, kw)

    Py_TYPE(X(0)).tp_new = _trace_tp_new

    x = X(123)
    print(x)
    ```

    ```console
    (neo) (py3.venv) (g.env) kirr@deca:~/src/tools/go/pygolang$ cythonize -i x.pyx
    Compiling /home/kirr/src/tools/go/pygolang/x.pyx because it changed.
    [1/1] Cythonizing /home/kirr/src/tools/go/pygolang/x.pyx
    running build_ext
    building 'x' extension
    ...
    x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/home/kirr/src/wendelin/venv/py3.venv/include -I/usr/include/python3.9 -c /home/kirr/src/tools/go/pygolang/x.c -o /home/kirr/src/tools/go/pygolang/tmpqkz1r96s/home/kirr/src/tools/go/pygolang/x.o
    x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 /home/kirr/src/tools/go/pygolang/tmpqkz1r96s/home/kirr/src/tools/go/pygolang/x.o -o /home/kirr/src/tools/go/pygolang/x.cpython-39-x86_64-linux-gnu.so
    ```

    ```console
    (neo) (py3.venv) (g.env) kirr@deca:~/src/tools/go/pygolang$ python -c 'import x'
    Ошибка сегментирования (стек памяти сброшен на диск)
    ```

    ```console
    (neo) (py3.venv) (g.env) kirr@deca:~/src/tools/go/pygolang$ gdb python core
    ...
    Reading symbols from python...
    Reading symbols from /usr/lib/debug/.build-id/f9/02f8a561c3abdb9c8d8c859d4243bd8c3f928f.debug...
    [New LWP 218557]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Core was generated by `python -c import x'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  _Py_INCREF (op=0x0) at /usr/include/python3.9/object.h:408
    408         op->ob_refcnt++;

    (gdb) bt 5
    #0  _Py_INCREF (op=0x0) at /usr/include/python3.9/object.h:408
    #1  __pyx_f_1x__trace_tp_new (__pyx_v_cls=0x7f5ce75e6880 <__pyx_type_1x_X>, __pyx_v_args=(123,), __pyx_v_kw=0x0) at /home/kirr/src/tools/go/pygolang/x.c:1986
    #2  0x000000000051dd7e in type_call (type=type@entry=0x7f5ce75e6880 <__pyx_type_1x_X>, args=args@entry=(123,), kwds=kwds@entry=0x0)
        at ../Objects/typeobject.c:1014
    #3  0x00007f5ce75df8d4 in __Pyx_PyObject_Call (func=<type at remote 0x7f5ce75e6880>, arg=(123,), kw=0x0) at /home/kirr/src/tools/go/pygolang/x.c:3414
    #4  0x00007f5ce75df276 in __pyx_pymod_exec_x (__pyx_pyinit_module=<optimized out>) at /home/kirr/src/tools/go/pygolang/x.c:3017
    (More stack frames follow...)

    (gdb) f 1
    #1  __pyx_f_1x__trace_tp_new (__pyx_v_cls=0x7f5ce75e6880 <__pyx_type_1x_X>, __pyx_v_args=(123,), __pyx_v_kw=0x0) at /home/kirr/src/tools/go/pygolang/x.c:1986
    1986      __Pyx_INCREF(__pyx_v_kw);
    ```

-> Change newfunc signature to use PyObject* instead of object to fix it.

With this fix, and test example updates to account for object -> PyObject* change as follows ...

    --- a/x.pyx.kirr
    +++ b/x.pyx
    @@ -1,5 +1,5 @@
     # cython: language_level=3
    -from cpython cimport newfunc, type as cpytype, Py_TYPE
    +from cpython cimport newfunc, type as cpytype, Py_TYPE, PyObject

     cdef class X:
         cdef int i
    @@ -10,8 +10,12 @@ cdef class X:

     cdef newfunc _orig_tp_new = Py_TYPE(X(0)).tp_new

    -cdef object _trace_tp_new(cpytype cls, object args, object kw):
    -    print('_trace_tp_new', cls, args, kw)
    +cdef object xobject(PyObject* x):
    +    return "null"  if x == NULL  else \
    +           <object>x
    +
    +cdef object _trace_tp_new(cpytype cls, PyObject* args, PyObject* kw):
    +    print('_trace_tp_new', cls, xobject(args), xobject(kw))
         return _orig_tp_new(cls, args, kw)

     Py_TYPE(X(0)).tp_new = _trace_tp_new

... it works as expected without crashing:

    $ python -c 'import x'
    _trace_tp_new <type 'x.X'> (123,) null
    X(123)

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

Test added in 5c900c59

PyPy gives a slightly different error message for the unsupported operation

* BUG: Fortify object buffers against included NULLs

While NumPy tends to not actively create object buffers initialized
only with NULL (rather than filled with None), at least older versions
of NumPy did do that.  And NumPy guards against this.

This guards against embedded NULLs in object buffers interpreting
a NULL as None (and anticipating a NULL value also when setting
the buffer for reference count purposes).

Closes gh-4858

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

Patch is against 0.29.x branch (to fix both versions of the
documentation).

By explicitly setting the result type

* MNT: always require va_start to have two arguments

https://github.com/python/cpython/pull/93215 chance CPython to always use the
2-input version of va_start and dropped defining HAVE_STDARG_PROTOTYPES.  This
resulted in the 1-argument version being used when compiling cython source
which fails

This makes cython also always use the 2-argument version.

* Remove blank line

* FIX: version gate 2-argument va_start checking to py311

See https://github.com/cython/cython/pull/4764

Move from deprecated find_loader() to find_spec() for setting up the import time package path (GH-4764)

Closes https://github.com/cython/cython/issues/4763

This reverts commit 74073417.

This reverts commit 74073417.

Move from deprecated find_loader() to find_spec() for setting up the import time package path (GH-4764)

Closes https://github.com/cython/cython/issues/4763

They prevent explicitly calling the base-class __contains__.

Closes https://github.com/cython/cython/issues/4785

Fix version detection and compile/runtime Python version warning with double-digit versions such as Py3.10 (GH-4777)

See https://github.com/cython/cython/issues/2542#issuecomment-1121484721

Closes https://github.com/cython/cython/issues/4637
See See https://github.com/cython/cython/issues/3556

* Acquire the GIL in nogil functions only when strictly needed on function exit, e.g. for cleaning up temp variables from with-gil blocks or adding tracebacks.

See https://github.com/cython/cython/issues/3554

* Make the GIL-avoidance in 7d99b0f0 actually work in nogil functions and not just nogil sections.

See https://github.com/cython/cython/issues/3558

This means that reverse operators (e.g. `__radd__`) won't be
hidden by the automatic wrapper that `PyType_Ready()` produces if
the forward method exists. Although they won't work as
in Python, they will be possible to look up and call explicitly.
This should make it easier to write code that's compatible with
Cython 0.29.x and Cython 3 (where reverse operators will be full supported).

Closes https://github.com/cython/cython/issues/4750