Factor-out subroutine to run tfunc in subprocess interpreter spawned with
`-X xopt=xval`. This helps clarity and later in addition to `-X
gpython.runtime` we will also need it to verify `-X gpython.strings`.

Previously test_strings_methods was testing a method via comparing bstr
and ustr results of .method() with similar result of unicode.method().
This works reasonably ok. However under gpython, when unicode will be
replaced with ustr, it will no longer compare results of bstr/ustr
methods with something good and external - indeed in that case bstr/ustr
.method() will be compared to result of ustr.method() which opens the
door for bugs to stay unnoticed.

-> Adjust the test to explicitly provide expected result for all entries
in the test vector. We make sure those results are good and match std
python because we also assert that unicode.method() matches it.

On py2 str.decode('string-escape') returns str, not unicode and this
property is actually being used and relied upon by Lib/pickle.py:

https://github.com/python/cpython/blob/v2.7.18-0-g8d21aa21f2c/Lib/pickle.py#L967-L977

We promised bstr to be drop-in replacement for str on py2, so let's
adjust its behaviour to match the original because if we do not,
unpickling strings will break when str is replaced by bstr under
gpython.

Do not add bstr.encode yet until we hit a real case where it is actually used.

repr(ustr|bstr) will change behaviour depending on whether we are
running under regular python, or gpython with string types replaced by
bstr/ustr. But this test is completely orthogonal to that. -> Let's
untie it from particular repr behaviour by emitting verified items in
quoted form + asserting their types in the code.

In ebd18f3f the code was ok but there is a thinko in test: it needs to
test all pickle protocols from 0 to _including_ HIGHEST_PROTOCOL.

    + ./trun python -m pytest -vvsx golang/golang_str_test.py
    ==================================== test session starts =====================================
    platform linux2 -- Python 2.7.18, pytest-4.6.11, py-1.11.0, pluggy-0.13.1 -- /home/kirr/src/tools/go/py2d.venv2023/bin/python
    cachedir: .pytest_cache
    rootdir: /home/kirr/src/tools/go/pygolang-xgpystr
    collected 64 items

    golang/golang_str_test.py::test_strings_basic Traceback (most recent call last):
      File "golang/_golang_str.pyx", line 2270, in golang._golang._xuniord
        return ord(u)
    ValueError: only single character unicode strings can be converted to Py_UCS4, got length 2
    Exception ValueError: 'only single character unicode strings can be converted to Py_UCS4, got length 2' in 'golang._golang._utf8_decode_rune' ignored

    (py2d.venv2023) kirr@deca:~/src/tools/go/pygolang-xgpystr$ python
    Python 2.7.18 (tags/2.7-dirty:8d21aa21f2c, Mar 30 2023, 07:38:40)
    [GCC 10.2.1 20210110] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from pygolang import *
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: No module named pygolang
    >>> from golang import *
    >>> ord('xy')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: ord() expected a character, but string of length 2 found
    >>> ord(b'xy')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: ord() expected a character, but string of length 2 found
    >>> ord(u'xy')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: ord() expected a character, but string of length 2 found
    >>> ord(b('xy'))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: ord() expected a character, but string of length 2 found
    >>> ord(u('xy'))
    Traceback (most recent call last):
      File "golang/_golang_str.pyx", line 2270, in golang._golang._xuniord
        return ord(u)
    ValueError: only single character unicode strings can be converted to Py_UCS4, got length 2
    Exception ValueError: 'only single character unicode strings can be converted to Py_UCS4, got length 2' in 'golang._golang._utf8_decode_rune' ignored
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "golang/_golang_str.pyx", line 157, in golang._golang.pyu
        us = _pyu(pyustr, s)
      File "golang/_golang_str.pyx", line 195, in golang._golang._pyu
        s = _utf8_decode_surrogateescape(s)
      File "golang/_golang_str.pyx", line 2198, in golang._golang._utf8_decode_surrogateescape
        emit(_xunichr(r))
      File "golang/_golang_str.pyx", line 2286, in golang._golang._xunichr
        return unichr(0xd800 + (uh >> 10)) + \
    ValueError: unichr() arg not in range(0x10000) (narrow Python build)

It was broken in 50b8cb7e (strconv: Move functionality related to UTF8 encode/decode into _golang_str)

Pygolang stopped to work on Windows in 2019 starting from 8fa3c15b (Start using
Cython and providing Cython/nogil API). Restore it now.

Linux and macOS was working before. And we just added Windows support in
the previous patches.

When underlying pygfobj is FileObjectThread its .readinto() leads to
deadlock because it is no cooperative(*). This manifests as
test_pyx_os_pipe_cpp hang when run by gpython on windows.

-> Workaround this by reading first into intermediate buffer and then
copying data to buffer that user provided.

After this the deadlock is gone but test_pyx_os_pipe_cpp starts to fail
and crash randomly. That's because similarly to channels we need to
care and not access a buffer if it is located on stack and owning
greenlet is inactive. Because when a greenlet is inactive, its stack is
reused by another active greenlet and writing/reading to on-stack memory
accesses that second greenlet stack, corrupting it on write.

-> do the same what we do in chan operations: use intermediate on-heap
buffer to protect original user's buffer to be accesses because it might
be located on stack. That's what actually happens in
test_pyx_os_pipe_cpp where two goroutines read and write to each other
via pipe and using on-stack located buffers. And becuase on windows
pipes, like regular files, are wrapped with FileObjectThread, when
reading greenlet becomes suspended waiting for read reasul, it will be
another greenlet to run on its stack, write to another end of a pipe,
wakeup IO thread, which will write the data to requested buffer on G1
stack and oops - it was G2 there.

(*) see https://github.com/gevent/gevent/pull/1948 for details

Because on Windows it is \ and using / for it to scan in path fails and
leads to test_pymain_opt failure:

     E             Full diff:
     E               [
     E                'sys.flags.debug:      0',
     E                'sys.flags.optimize:   0',
     E                '__debug__:            True',
     E                'assert:               True',
     E                'docstrings:           True',
     E                'import mod.py:        '
     E             -  'C:\\users\\kirr\\Temp\\modpy_imports_fromvmgs8go4\\__pycache__/mod.cpython-310.pyc',
     E             ?                                            ^^  ----
     E             +  'C:\\users\\kirr\\Temp\\modpy_imports_from850gb81s\\__pycache__/mod.cpython-310.pyc',
     E             ?                                            ^^^ +++
     E               ]

Here the difference is because gpython/testprog/print_opt.py failed to
detect tmpd prefix and strip it.

In several places we were preparing repr of a string as '%s' which works
ok most of the time but leads to failure if string contains '\'
characters e.g. if it represents a path and we are running on windows:

        def test_pymain():
            from golang import b

            ....

            # -m <module>
            _ = pyout(['-m', 'hello', 'abc', 'def'], cwd=testdata)
            # realpath rewrites e.g. `local/lib -> lib` if local/lib is symlink
            hellopy = realpath(join(testdata, 'hello.py'))
    >       assert _ == b"hello\nworld\n['%s', 'abc', 'def']\n" % b(hellopy)
    E       assert b"hello\nworld\n['Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\pygolang\\\\gpython\\\\testdata\\\\hello.py', 'abc', 'def'
    ]\n" == b"hello\nworld\n['Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\gpython\\testdata\\hello.py', 'abc', 'def']\n"
    E         At index 17 diff: b'\\' != b'h'
    E         Full diff:
    E           (
    E         -  b"hello\nworld\n['Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\gpytho"
    E         ?                                                                  ------------
    E         +  b"hello\nworld\n['Z:\\\\home\\\\kirr\\\\src\\\\tools\\\\go\\\\pygo-win\\\\pygo"
    E         ?                        ++    ++        ++   ++         ++  ++            ++
    E         -  b"n\\testdata\\hello.py', 'abc', 'def']\n",
    E         +  b"lang\\\\gpython\\\\testdata\\\\hello.py', 'abc', 'def']\n",
    E         ?    ++ ++++++++++++++            ++
    E           )

    gpython\gpython_test.py:183: AssertionError

-> Fix it by preparing repr via repr(...) properly.

On Windows if geventmp is present gpython startup fails:

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>gpython
    Traceback (most recent call last):
      File "C:\Program Files\Python310\lib\runpy.py", line 196, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "C:\Program Files\Python310\lib\runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\Scripts\gpython.exe\__main__.py", line 7, in <module>
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 450, in main
        pymain(argv, init)
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 223, in pymain
        init()
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 428, in init
        _ = monkey.patch_all(thread=patch_thread)      # XXX sys=True ?
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\monkey.py", line 1255, in patch_all
        _notify_patch(events.GeventWillPatchAllEvent(modules_to_patch, kwargs), _warnings)
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\monkey.py", line 190, in _notify_patch
        notify_and_call_entry_points(event)
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\events.py", line 105, in notify_and_call_entry_points
        subscriber(event)
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\monkey.py", line 160, in _patch_mp
        _patch_module("_mp.3._mp_util", _patch_module=True, _package_prefix='geventmp.')
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\monkey.py", line 121, in _patch_module
        gevent_module = import_module(_package_prefix + name)
      File "C:\Program Files\Python310\lib\importlib\__init__.py", line 126, in import_module
        return _bootstrap._gcd_import(name[level:], package, level)
      File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
      File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
      File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
      File "<frozen importlib._bootstrap_external>", line 883, in exec_module
      File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\geventmp\_mp\3\_mp_util.py", line 16, in <module>
        from gevent.os import _watch_child
    ImportError: cannot import name '_watch_child' from 'gevent.os' (Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages\gevent\os.py)

That happens because geventmp does not support windows actually.

-> Fix it by requiring geventmp to be present only on non-windows.

Adjust related comment as https://github.com/karellen/geventmp/pull/2 has been merged long ago.

On windows setuptools install gpython.exe and gpython-script.py while
pip/distlib install gpython.exe with gpython-script sometimes embedded
into gpython.exe itself with argv[0] pointing to 'gpython' without .exe
suffix. This leads to gpython startup failure:

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>gpython
    Traceback (most recent call last):
      File "C:\Program Files\Python310\lib\runpy.py", line 196, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "C:\Program Files\Python310\lib\runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\Scripts\gpython.exe\__main__.py", line 7, in <module>
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 437, in main
        pymain(argv, init)
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 79, in pymain
        if not _is_buildout_script(exe):
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\gpython\__init__.py", line 442, in _is_buildout_script
        with open(path, 'rb') as f:
    FileNotFoundError: [Errno 2] No such file or directory: 'Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\1.wenv\\Scripts\\gpython'

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang>dir ../1.wenv/scripts/gpython*

    Directory of Z:\home\kirr\src\tools\go\pygo-win\1.wenv\scripts

    26.04.2023     14:17       108,404  gpython.exe
           1 file                   108,404 bytes
           0 directories     88,508,866,560 bytes free

-> Adjust pymain to handle this case accordingly.

On windows upon terminating signal reception exict code of the process
is always 3 instead of -signo. And so test_signal_all was failing as

        def test_signal_all():
            retcode, out, _ = _pyrun([dir_testprog + "/signal_test_all.py"], stdout=PIPE)
            assert b"ok (notify)"        in out
            assert b"ok (ignore)"        in out
            assert b"terminating ..."    in out
    >       assert retcode == -syscall.SIGTERM.signo
    E       assert 3 == -15
    E        +  where 15 = os.Signal(15).signo
    E        +    where os.Signal(15) = syscall.SIGTERM

- There is no e.g. signal.SIGKILL on windows:

    golang/os/signal_test.py::test_signal_all Traceback (most recent call last):
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\os\testprog\signal_test_all.py", line 82, in <module>
        main()
      File "Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\os\testprog\signal_test_all.py", line 39, in main
        allsigv.remove(syscall.SIGKILL) # SIGKILL/SIGSTOP cannot be caught
    AttributeError: module 'golang.syscall' has no attribute 'SIGKILL'. Did you mean: 'SIGILL'?

  -> filter-out signals conditionally depending on their presence.

- Need to also filter-out SIGILL/SIGABRT because upon reception MSVC
  runtime terminates process.

Because on Windows os.kill unconditionally terminates target process,
even if own self, instead of sending it any kind of signal.

We use SIGUSR1/SIGUSR2 mainly in this test, but those signals are not
available on Windows:

        @func
        def test_signal():
            # Notify/Stop with wrong chan dtype -> panic
            _ = panics("pychan: channel type mismatch")
    >       with _:  signal.Notify(chan(2), syscall.SIGUSR1)
    E       AttributeError: module 'golang.syscall' has no attribute 'SIGUSR1'

-> Use SIGTERM/SIGINT if SIGUSR1/SIGUSR2 are not available.

Don't want to use SIGTERM/SIGINT unconditionally because those signals are
better to leave for the job control so that e.g. nxdtest can properly kill
spawned pygolang tests.

On Windows in text mode files are opened with encoding=locale.getdefaultlocale()
which is CP125X instead of UTF-8 even if $PYTHONIOENCODING=UTF-8. This
way e.g. test_strings_print fail as:

    E           Failed: not equal:
    E           Expected:
    E               print(qq(b)): "привет αβγ b"
    E               print(qq(u)): "привет αβγ u"
    E           Got:
    E               print(qq(b)): "привет αβγ b"
    E               print(qq(u)): "привет αβγ u"

where "Expected" was read from golang/testprog/golang_test_str.txt and
decoded wrongly.

-> Fix it by always opening files for reading in binary mode and
utf8-decoding manually, if needed, everywhere.

golang: tests: Spawn subprocess python with $PYTHONIOENCODING set to encoding of stdin/stdout/stderr

We need to do it because on Windows `python x.py | ...` runs with stdio
encoding set to cp125X even if just `python x.py` runs with stdio
encoding=UTF-8.

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py
    print(qq(b)): "привет b"
    print(qq(u)): "привет u"

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py |more
    print(qq(b)): "яЁштхЄ b"
    print(qq(u)): "яЁштхЄ u"

    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>python golang_test_str.py >aaa.txt
    (1.wenv) Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\testprog>type aaa.txt
    print(qq(b)): "яЁштхЄ b"
    print(qq(u)): "яЁштхЄ u"

Which leads to the following test_strings_print failure:

    E           Failed: not equal:
    E           Expected:
    E               print(qq(b)): "привет b"
    E               print(qq(u)): "привет u"
    E           Got:
    E               print(qq(b)): "������ b"
    E               print(qq(u)): "������ u"

We also change golang_test_str.py to print not only russian and english
letters, but also greek ones. This is to make sure that stdout IO encoding would
not go cp125X unnoticed because then printing will fail with UnicodeEncodeError.

Note: in the above example both got and expected are wrong. Via
$PYTHONIOENCODING we only fix "got" and we will fix "expected" in the followup
patch. After current patch test_strings_print result is

    E           Failed: not equal:
    E           Expected:
    E               print(qq(b)): "привет αβγ b"
    E               print(qq(u)): "привет αβγ u"
    E           Got:
    E               print(qq(b)): "привет αβγ b"
    E               print(qq(u)): "привет αβγ u"

Apparently on Windows pytest detects terminal width differently than on
Linux/macOS and the test fails as

    E           Failed: not equal:
    E           Differences (unified diff with -expected +actual):
    E               @@ -1,5 +1,12 @@
    E               -...
    E               -_____________________________________ main _____________________________________
    E               -../__init__.py:...: in _
    E               +============================= test session starts =============================
    E               +platform win32 -- Python 3.10.11, pytest-7.3.1, pluggy-1.0.0
    E               +rootdir: PYGOLANG
    E               +collected 1 item
    E               +<BLANKLINE>
    E               +golang_test_defer_excchain.py F                                          [100%]
    E               +<BLANKLINE>
    E               +================================== FAILURES ===================================
    E               +____________________________________ main _____________________________________
    E               +../__init__.py:106: in _
    E                    return f(*argv, **kw)
    E                golang_test_defer_excchain.py:42: in main
    E               @@ -8,6 +15,6 @@
    E                <BLANKLINE>
    E                During handling of the above exception, another exception occurred:
    E               -../__init__.py:...: in __exit__
    E               -    ...
    E               +../__init__.py:183: in __exit__
    E               +    d()
    E                golang_test_defer_excchain.py:31: in d1
    E                    raise RuntimeError("d1: aaa")
    E               @@ -15,9 +22,9 @@
    E                <BLANKLINE>
    E                During handling of the above exception, another exception occurred:
    E               -../__init__.py:...: in __exit__
    E               -    ...
    E               +../__init__.py:183: in __exit__
    E               +    d()
    E                golang_test_defer_excchain.py:33: in d2
    E                    1/0
    E               -E   ZeroDivisionError: ...
    E               +E   ZeroDivisionError: division by zero
    E                <BLANKLINE>
    E                During handling of the above exception, another exception occurred:
    E               @@ -25,3 +32,5 @@
    E                    raise RuntimeError("d3: bbb")
    E                E   RuntimeError: d3: bbb
    E               -=========================== ...
    E               +=========================== short test summary info ===========================
    E               +FAILED golang_test_defer_excchain.py::main - RuntimeError: d3: bbb
    E               +============================== 1 failed in 1.45s ==============================

-> Fix it by not requesting header to be of particular width.

On windows print emits \r\n instead of just \n. Here is how e.g.
test_defer_excchain_dump fails without normalization:

    E           Failed: not equal:
    E           Differences (unified diff with -expected +actual):
    E               @@ -1,42 +1,43 @@
    E               -Traceback (most recent call last):
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
    E               -    return f(*argv, **kw)
    E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 42, in main
    E               -    raise RuntimeError("err")
    E               -RuntimeError: err
    E               -<BLANKLINE>
    E               -During handling of the above exception, another exception occurred:
    E               -<BLANKLINE>
    E               -Traceback (most recent call last):
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
    E               -    ...
    E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 31, in d1
    E               -    raise RuntimeError("d1: aaa")
    E               -RuntimeError: d1: aaa
    E               -<BLANKLINE>
    E               -During handling of the above exception, another exception occurred:
    E               -<BLANKLINE>
    E               -Traceback (most recent call last):
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
    E               -    ...
    E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 33, in d2
    E               -    1/0
    E               -ZeroDivisionError: ...
    E               -<BLANKLINE>
    E               -During handling of the above exception, another exception occurred:
    E               -<BLANKLINE>
    E               -Traceback (most recent call last):
    E               -  ... "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 45, in <module>
    E               -    main()
    E               -  ...
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in _
    E               -    with __goframe__:
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
    E               -    ...
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
    E               -    ...
    E               -  File "PYGOLANG/golang/__init__.py", line ..., in __exit__
    E               -    ...
    E               -  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 35, in d3
    E               -    raise RuntimeError("d3: bbb")
    E               -RuntimeError: d3: bbb
    E               +Traceback (most recent call last):
    E               +  File "PYGOLANG/golang/__init__.py", line 106, in _
    E               +    return f(*argv, **kw)
    E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 42, in main
    E               +    raise RuntimeError("err")
    E               +RuntimeError: err
    E               +
    E               +During handling of the above exception, another exception occurred:
    E               +
    E               +Traceback (most recent call last):
    E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
    E               +    d()
    E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 31, in d1
    E               +    raise RuntimeError("d1: aaa")
    E               +RuntimeError: d1: aaa
    E               +
    E               +During handling of the above exception, another exception occurred:
    E               +
    E               +Traceback (most recent call last):
    E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
    E               +    d()
    E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 33, in d2
    E               +    1/0
    E               +ZeroDivisionError: division by zero
    E               +
    E               +During handling of the above exception, another exception occurred:
    E               +
    E               +Traceback (most recent call last):
    E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 45, in <module>
    E               +    main()
    E               +  File "Z:\home\kirr\src\tools\go\pygo-win\1.wenv\lib\site-packages/decorator.py", line 232, in fun
    E               +    return caller(func, *(extras + args), **kw)
    E               +  File "PYGOLANG/golang/__init__.py", line 105, in _
    E               +    with __goframe__:
    E               +  File "PYGOLANG/golang/__init__.py", line 182, in __exit__
    E               +    with __goframe__:
    E               +  File "PYGOLANG/golang/__init__.py", line 182, in __exit__
    E               +    with __goframe__:
    E               +  File "PYGOLANG/golang/__init__.py", line 183, in __exit__
    E               +    d()
    E               +  File "PYGOLANG/golang/testprog/golang_test_defer_excchain.py", line 35, in d3
    E               +    raise RuntimeError("d3: bbb")
    E               +RuntimeError: d3: bbb

Else on Windows e.g. test_defer_excchain_traceback fails as

    E           Failed: not equal:
    E           Differences (unified diff with -expected +actual):
    E               @@ -1,8 +1,8 @@
    E                Traceback (most recent call last):
    E               -  File "PYGOLANG/golang/golang_test.py", line ..., in test_defer_excchain_traceback
    E               +  File "PYGOLANG\golang\golang_test.py", line 1524, in test_defer_excchain_traceback
    E                    alpha()
    E               -  File "PYGOLANG/golang/golang_test.py", line ..., in alpha
    E               +  File "PYGOLANG\golang\golang_test.py", line 1521, in alpha
    E                    beta()
    E               -  File "PYGOLANG/golang/golang_test.py", line ..., in beta
    E               +  File "PYGOLANG\golang\golang_test.py", line 1520, in beta
    E                    raise RuntimeError("gamma")
    E                RuntimeError: gamma

Else it fails to import on Windows:

    collecting ... 05c8:err:module:import_dll Library libgolang.dll (which is needed by L"Z:\\home\\kirr\\src\\tools\\go\\pygo-win\\pygolang\\golang\\_golang.cp310-win_amd64.pyd") not found
    collected 0 items / 1 error

    =========================================================== ERRORS ===========================================================
    ___________________________________________ ERROR collecting golang/golang_test.py ___________________________________
    ImportError while importing test module 'Z:\home\kirr\src\tools\go\pygo-win\pygolang\golang\golang_test.py'.
    Hint: make sure your test modules/packages have valid Python names.
    Traceback:
    C:\Program Files\Python310\lib\importlib\__init__.py:126: in import_module
        return _bootstrap._gcd_import(name[level:], package, level)
    golang\__init__.py:45: in <module>
        from golang._golang import _pysys_exc_clear as _sys_exc_clear
    E   ImportError: DLL load failed while importing _golang: Модуль не найден.

We need to increase required setuptools_dso version because dylink_prepare_dso
and generation of *_dsoinfo.py modules was done after setuptools_dso 2.

On Windows this files are generated when linking alongside *.dll files
if there are exported symbols.

See also https://github.com/mdavidsaver/setuptools_dso/pull/25.

Libpyxruntime by definition contains python-specific code and we already
compile it with include path having python includes in it. However on
windows pyconfig.h contains

    #pragma comment(lib,"python3.lib")

which instructs the linker to automatically link to that library. And
without proper library path the link fails:

    Z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\bin\Hostx64\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:build\lib.win-amd64-cpython-31
    0\golang\runtime /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\lib\x64 /LIBPATH:z:\home\kirr\src\tools\go\pygo-win\BuildTools\kits\10\lib\10.0.22000.0\ucrt\x64 /LIBPATH:z:\h
    ome\kirr\src\tools\go\pygo-win\BuildTools\kits\10\lib\10.0.22000.0\um\x64 libgolang.lib build\temp.win-amd64-cpython-310\Release\golang/runtime/libpyxruntime.obj /OUT:build\lib.win-amd64-cpython-310\golang\ru
    ntime\libpyxruntime.dll /IMPLIB:build\lib.win-amd64-cpython-310\golang\runtime\libpyxruntime.lib
    LINK : fatal error LNK1104: cannot open file 'python310.lib'

-> Fix it by providing proper library path for python.dll .

We need to do it ourselves only for libpyxruntime dso because for py
extensions this is automatically done by distutils out of the box.

On Windows rthere is no fcntl

    golang/runtime\_runtime_gevent.cpp(4811): error C3861: 'S_ISBLK': identifier not found
    golang/runtime\_runtime_gevent.cpp(4823): error C2039: 'Fcntl': is not a member of 'golang::internal::syscall'
    .\golang/runtime/internal/syscall.h(36): note: see declaration of 'golang::internal::syscall'
    golang/runtime\_runtime_gevent.cpp(4823): error C2065: 'F_GETFL': undeclared identifier
    golang/runtime\_runtime_gevent.cpp(4823): error C3861: 'Fcntl': identifier not found
    golang/runtime\_runtime_gevent.cpp(4870): error C2065: 'O_ACCMODE': undeclared identifier
    golang/runtime\_runtime_gevent.cpp(4889): error C2039: 'Fcntl': is not a member of 'golang::internal::syscall'
    .\golang/runtime/internal/syscall.h(36): note: see declaration of 'golang::internal::syscall'
    golang/runtime\_runtime_gevent.cpp(4889): error C2065: 'F_SETFL': undeclared identifier
    golang/runtime\_runtime_gevent.cpp(4889): error C2065: 'O_NONBLOCK': undeclared identifier
    golang/runtime\_runtime_gevent.cpp(4889): error C3861: 'Fcntl': identifier not found

and even if there would be gevent does not provide cooperative version
of FileObject for non-POSIX platforms.

-> Always use FileObjectThread on windows even for pipes.

There is no fcntl on windows. Named pipes can be set into nonblocking
mode via SetNamedPipeHandleState(PIPE_NOWAIT).

On MSVC there is no sigaction and we have to use signal. Fortunately
our sigaction usage in os/signal can be practically emulated because we
do not use all features of sigaction and because on MSVC there is
SIG_GET signal extension to query current signal handler without
resetting it.

Because the emulation is limited we keep it in os/signal.cpp instead of
adjusting syscall::Sigaction .

On MSVC we will need to use signal(2), because there is no sigaction,
and sigaction will be partly emulated through that. Move signal setting
code into common place as a preparatory step.

- there is no strerror_r, but strerror_s instead
- fcntl is not supported
- we need to explicitly tell open to open files in binary mode
- pipes are created via _pipe and explicitly in binary mode
- there is no sigaction.

This way e.g. O_CLOEXEC can be passed in at pipe creation time removing
potential race in between pipe+fcntl vs exec in the middle. It will also
help in windows porting in follow-up patches becuase there is no fcntl
on Windows, but pipe with O_CLOEXEC semantic can be created directly
with flags=_O_NOINHERIT.

There is no fork on windows and that we do not need to install atfork
handler at all.

    golang/runtime/internal/atomic.cpp(23): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory

- there is no __attribute__ on that compiler
- sadly va_start is rejected to work on reference:

    z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\include\vadefs.h(194): error C2338: static_assert failed: 'va_start argument must not have reference type and must not be parenthesized'
    golang/fmt.cpp(53): note: see reference to class template instantiation '__vcrt_assert_va_start_is_not_reference<const golang::string &>' being compiled

  -> change format from string& to be string in sprintf.

  Probably it should be ok in practice from performance point of view because
  string contains only pointer to data, not the data itself.

- There is no S_IRUSR & friends  -> use _S_IREAD & co.
- Tthere is no sys_siglist       -> kind-of define it ourselves for all documented signals.

list_entry, as provided by linux/list.h, uses statement expressions(*) which
are not supported by MSVC:

    #define list_entry(ptr, type, member) ({              \
            const typeof( ((type *)0)->member ) *__mptr = (ptr);   \
            (type *)( (char *)__mptr - offsetof(type,member) );})

    golang/runtime/libgolang.cpp(439): error C2059: syntax error: '{'
    golang/runtime/libgolang.cpp(439): error C2143: syntax error: missing ';' before '{'
    golang/runtime/libgolang.cpp(439): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
    golang/runtime/libgolang.cpp(439): error C2440: 'initializing': cannot convert from 'list_head' to 'int'
    golang/runtime/libgolang.cpp(439): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
    golang/runtime/libgolang.cpp(439): error C2143: syntax error: missing ';' before '*'
    golang/runtime/libgolang.cpp(439): error C2065: '__mptr': undeclared identifier
    golang/runtime/libgolang.cpp(439): error C2059: syntax error: ')'

-> work it around by defining list_entry with C++ lambda.

(*) https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html

There is no std::random_shuffle on `MSVC /std:c++20` because it was removed in C++17:

    golang/runtime/libgolang.cpp(946): error C2039: 'random_shuffle': is not a member of 'std'
    z:\home\kirr\src\tools\go\pygo-win\BuildTools\vc\tools\msvc\14.35.32215\include\random(34): note: see declaration of 'std'
    golang/runtime/libgolang.cpp(946): error C3861: 'random_shuffle': identifier not found

    https://en.cppreference.com/w/cpp/algorithm/random_shuffle

We need unistd.h because e.g. `cimport posix.stat` forces inclusion of unistd.h
even if we use part of posix.stat that is available everywhere.

We use bzero in libgolang.cpp - provide it in similar way via compat
strings.h because on windows there is only string.h (no "s" in the end).

We also use mode_t in several places - provide it via typedef in
libgolang.h directly, because fcntl.h is present on MSVC.

MSVC does not accept -std=c++11 but instead accepts /std:c++11. We cannot
use that however because with /std:c++11 compilation fails with

    .\golang/libgolang.h(280): error C7555: use of designated initializers requires at least '/std:c++20'
    .\golang/libgolang.h(294): error C7555: use of designated initializers requires at least '/std:c++20'
    .\golang/libgolang.h(308): error C7555: use of designated initializers requires at least '/std:c++20'

for

    276 // _selsend creates `_chansend(ch, ptx)` case for _chanselect.
    277 static inline
    278 _selcase _selsend(_chan *ch, const void *ptx) {
    279     _selcase _ = {
    280         .ch     = ch,			<-- NOTE
    281         .op     = _CHANSEND,
    282         .flags  = (enum _selflags)0,
    283         .user   = 0xff,
    284     };

and similar places.

-> Use /std:c++20 instead as MSVC advices  (WOW designated initializers are C99
and it took 21 years for C++ to catch up).

We also need to adjust exception handling mode into "fully conformant" instead
of "assume extern C cannot throw" setuptools default so that `panic` and other
extern C libgolang functions generate exceptions that could be caught
instead of crashing programs.

For C vs C++ flags we also need to adjust our build_ext, because the way
setuptools/distutils organize compilation for MSVC is different from
UNIX compilers.

We already reuse golang.pyx.build in setup.py to build Extensions, but
DSOs were built via setuptools_dso directly so far. To support Windows
we will soon need to adjust compilation flags for both Extensions and
DSOs. It makes sense to first concentrate build recipes in one place
before doing that.

-> Move/factor DSOs build flags into golang.pyx.build and reuse that
from setup.