cmeel-glpk: Add version 5.0 - #4848

GLPK (GNU Linear Programming Kit) wraps its own upstream autotools
build (./configure && make && make check && make install via
ExternalProject_Add) through the cmeel build-backend, same shape
already proven here by cmeel-fmt/cmeel-gmp/cmeel-gklib/cmeel-cppad/
cmeel-coinutils/cmeel-lapack: one has-sitelib=false py3-none wheel
holding only the shared library, headers, and the glpsol command-line
tool, no Python extension to build per interpreter. Leaf dependency
(requires_dist: cmeel only) - no cmeel-* build-time dependency to
resolve from this registry.

GPL-3.0-only (GNU GLPK itself). Same licensing gap already found and
fixed for cmeel-m4 in this same mining pass: re-read
patching-and-licensing.md directly, confirming the documented GPL
procedure (the collect-gpl-sources job) is scoped to GPL components
pulled in from our own build environment, not to porting a project
whose own upstream source happens to be GPL. Confirmed against the
real published x86_64 wheel (cmeel_glpk-5.0-0-py3-none-manylinux_2_28_x86_64.whl,
unzip -l) that it ships no LICENSE/COPYING file at all, same gap as
cmeel-m4, in the upstream wrapper itself. GLPK's own release tarball
ships COPYING at its top level (confirmed: tar -tzf glpk-5.0.tar.gz).
This wrapper's ExternalProject_Add(glpk ...) uses BUILD_IN_SOURCE ON
with no explicit SOURCE_DIR, so CMake's own documented default applies
(confirmed against the real ExternalProject.cmake module source and
its extractfile.cmake.in single-top-level-directory-rename logic, not
guessed): SOURCE_DIR = <CMAKE_CURRENT_BINARY_DIR>/glpk-prefix/src/glpk,
so COPYING lands there once the build step runs, before the top-level
install() rules execute. Added a second install(FILES ...) rule beside
the wrapper's existing "dummy README.md" one, pointing at that path -
patching the build to add the missing LICENSE, per
patching-and-licensing.md's documented remedy; will send the same fix
upstream to cmake-wheel/cmeel-glpk.

No architectural riscv64 concern: GLPK is portable C with no
SIMD/arch-specific code path. Verified against the real published
x86_64 wheel that the actual lib filename is libglpk.so.40.3.1 and that
glp_version is a real exported symbol (nm -D), rather than guessing.

docs/packages/cmeel-glpk.yaml: license GPL-3.0-only; the built wheel
now carries GLPK's own COPYING via the CMakeLists.txt patch above.

GLPK 5.0's own bundled config.guess predates riscv64 recognition
entirely (gotcha 138, same root cause already fixed for msprime's GSL
dependency), confirmed from the real cp312 CI log (job 131256088489):
"./config.guess: unable to guess system type" / "configure: error:
cannot guess build type; you must specify one", config.guess
timestamp = 2012-09-25 in the log output itself.

ExternalProject_Add(glpk ...) has no PATCH_COMMAND of its own. Add one
copying the manylinux image's own current automake config.guess/
config.sub into the extracted source tree before configure runs (same
BUILD_IN_SOURCE ON layout the prior COPYING-install fix already relies
on, so the patch step's cwd is the extracted GLPK source) - the exact
fix shape build-msprime.yml already uses for GSL 2.8's identical gap.
Verified the sed insertion against a fresh clone of the real wrapper
tag v5.0.c0, not guessed: PATCH_COMMAND lands directly after
BUILD_IN_SOURCE ON, before CONFIGURE_COMMAND.