Add regression tests for MemoryDenyWriteExecute=true

[geofft]

As reported in #956, executable stacks cause thread creation to fail under MemoryDenyWriteExecute=true. In kernel 6.3+ (which the GitHub Actions runners should have) this is implemented using prctl(PR_SET_MDWE). In older versions systemd uses a more complicated seccomp filter.

[geofft]

Fails locally on an existing release, although unfortunately Python's error message is not great:

$ BUILD_OPTIONS= TARGET_TRIPLE=x86_64-linux-gnu uvx python3 -m unittest pythonbuild.disttests 
......E..Es.
======================================================================
ERROR: test_nx_thread_creation (pythonbuild.disttests.TestPythonInterpreter.test_nx_thread_creation)
Test that thread creation works under e.g. systemd's MemoryDenyWriteExecute.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ubuntu/python-build-standalone/pythonbuild/disttests/__init__.py", line 350, in test_nx_thread_creation
    t.start()
    ~~~~~~~^^
  File "/home/ubuntu/.local/share/uv/python/cpython-3.14.3-linux-x86_64-gnu/lib/python3.14/threading.py", line 1005, in start
    _start_joinable_thread(self._bootstrap, handle=self._os_thread_handle,
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                           daemon=self.daemon)
                           ^^^^^^^^^^^^^^^^^^^
RuntimeError: can't start new thread

[jjhelmus]

Is it worth isolating this from other tests via subprocess? Not a blocker to merging.

[geofft]

Is that easy to do? My gut feeling was the implementation complexity of doing that outweighed the potential benefits (especially since other failures under W^X are probably legitimate bugs) but if there's an easy way to do it I'm fine with it.