gevent: add build-gevent.yml for riscv64 wheels

[luhenry]

Adds .github/workflows/build-gevent.yml, building gevent 26.8.0 riscv64 wheels for cp312/cp313/cp314.

Based on the manylinux job of gevent's ci.yml and the scripts/releases/make-manylinux script it runs, narrowed to riscv64 and driven through cibuildwheel rather than make-manylinux's own docker run + per-interpreter loop (our matrix is one interpreter per job on a single arch).

Notes:

• Matrix is cp312/cp313/cp314, no cp314t. make-manylinux skips free-threaded interpreters outright ("Skipping no-gil build. The GIL is required.") and PyPI carries no cp3XXt gevent wheel.

• NO_CYTHON_COMPILE=true — Cython publishes no riscv64 wheel, so it builds from sdist in the container; upstream sets the same variable so that build does not also compile Cython's own accelerators.

• PIP_EXTRA_INDEX_URL — cffi (build requirement) and psutil (test extra) resolve from our registry; both are at the same version there as on PyPI.

• GEVENT_MANYLINUX is test-only. In the build phase it makes setup.py assume c-ares was configured by a separate step (upstream runs deps/c-ares/configure before entering the loop); we let setup.py configure it. In the test phase it is what selects upstream's manylinux-specific skips.

• CI=1 / TRAVIS=true are set for both phases as make-manylinux does; they are what makes setup.py treat gevent.resolver.cares as required rather than optional.

• A post-build step asserts the compiled extensions (including gevent/resolver/cares) are actually in the wheel — ARES.optional means a failed c-ares build otherwise degrades to a silently smaller wheel.

• CIBW_TEST_SOURCES: setup.py src/greentest examples — cibuildwheel runs test-command in an empty directory, where gevent's runner cannot climb to setup.py and so warns (No setup.py and src/greentest found) and skips the entire monkey-patched stdlib suite: 17 of its 86 test commands, silently. Staging those three paths (and deliberately not src/gevent) brings them back while leaving the installed wheel as the only importable gevent.

Testing mirrors upstream: the sanity checks for the libev-cext, libuv and libev-cffi loops and for gevent.ares, then the full python -m gevent.tests --second-chance suite with GEVENTTEST_USE_RESOURCES=-network, GEVENT_LOOP=libev-cext and PYTHONHASHSEED=8675309. Locally (macOS/arm64) that suite is 4324 tests over 75 files.

Licensing

patches/gevent/26.8.0/0001-package-the-licences-of-the-embedded-libev-libuv-and.patch — the wheel statically compiles deps/libev (BSD-2/GPL-2+), deps/libuv (MIT) and deps/c-ares (MIT) into the extension modules, but setup.py lists only 'LICENSE' in license_files, so upstream's wheels ship gevent's own licence alone. The vendored c-ares tree has no licence file at all, so the patch also restores LICENSE.md from c-ares 1.34.5 (the vendored version). Upstream-Status: To upstream. The test command asserts the six licence files are present in the installed dist-info/licenses/, so the patch cannot silently stop applying.

CI result

Run 32964011840 — all three matrix jobs green, publish dry-ran cleanly (3 wheels).

job	wheel	suite
cp312	gevent-26.8.0-cp312-cp312-manylinux_2_38_riscv64.manylinux_2_39_riscv64.whl, 17 extension modules	4334 tests (1033 skipped) in 76 files, 02:42
cp313	…-cp313-cp313-…whl, 17 extension modules	4358 tests (1044 skipped) in 77 files, 03:09
cp314	…-cp314-cp314-…whl, 17 extension modules	4871 tests (1073 skipped) in 86 files, 03:32

All three loops resolve as expected in every job (gevent.libev.corecext, gevent.libuv.loop.loop, gevent.libev.corecffi.loop) and gevent.ares imports.