cmeel-spirv-tools: Add version 2025.5 - #4850

SPIRV-Tools (Khronos's SPIR-V assembler/disassembler/validator/optimizer
toolchain) wraps a real KhronosGroup/SPIRV-Tools git submodule through the
cmeel build-backend, pointed at directly via pyproject.toml's `source =
"spirv-tools"` - unlike cmeel-m4/cmeel-glpk/cmeel-cddlib, which use
ExternalProject_Add to fetch an upstream tarball under cmeel's own generic
template CMakeLists.txt, this wrapper has no top-level CMakeLists.txt of
its own and builds the submodule's real, full build system directly.

Confirmed against the real KhronosGroup/SPIRV-Tools source at the
submodule's pinned commit: cmake_minimum_required(VERSION 3.22.1), already
above cmeel[build]'s CMake >= 4 floor of 3.5, and no -march=native/-mavx/
-msse or other x86-specific flag anywhere in its CMake tree or source/
tools/ directories - no patch needed for either gotcha that hit
cmeel-gklib/cmeel-metis. The wrapper's own cmeel.patch (auto-applied by
cmeel[build] itself - confirmed against the real cmeel package source,
cmeel/utils.py's patch() function, which runs `patch -p0 -N -i cmeel.patch`
whenever that file exists) swaps the submodule's own vendored-headers
lookup for find_package(SPIRV-Headers REQUIRED CONFIG), resolved from
cmeel-spirv-headers - a true py3-none-any header-only wheel already
published on public PyPI, confirmed not-applicable/no-port-needed in this
registry's own docs/packages/cmeel-spirv-headers.yaml.

Real published x86_64 wheel (cmeel_spirv_tools-2025.5-0-py3-none-
manylinux_2_28_x86_64.whl, confirmed via unzip -l) ships 11 binaries
(spirv-as/-opt/-link/-reduce/-diff/-lint/-val/-dis/-cfg/-objdump plus a
lesspipe.sh script), 5 static libs, and one shared lib
(libSPIRV-Tools-shared.so, exporting the plain C-ABI spvContextCreate
symbol among others - confirmed via nm -D) - a genuine multi-binary
toolchain build, more involved than the single-shared-lib shape every
other cmeel-* port here has used, but nothing in it is architecturally
riscv64-specific.

Same LICENSE gap already found and fixed for cmeel-m4/cmeel-glpk/
cmeel-cddlib: the real published wheel ships no LICENSE/COPYING file at
all. The wrapper's own pyproject.toml and PyPI METADATA both declare
"BSD-3-Clause", but the real submodule's own top-level LICENSE file
(confirmed at the pinned commit) is the Apache License, Version 2.0 - the
wrapper's declared license is simply wrong, the same class of mismatch
already found for cmeel-cddlib (whose pyproject.toml says generic "GPL"
when the real upstream COPYING is GPLv2-only). docs/packages below
records the real license. Unlike the ExternalProject-fetched packages'
CMAKE_CURRENT_BINARY_DIR extraction-path indirection, this submodule's
LICENSE file is already sitting in-tree at spirv-tools/LICENSE before the
build starts, so the fix is a direct install(FILES ...) rule beside the
submodule's own existing header-install block (confirmed unique anchor
line in the real source, not guessed).

docs/packages/cmeel-spirv-tools.yaml: license Apache-2.0 (the real
upstream license, not the wrapper's own mistaken "BSD-3-Clause" claim);
the built wheel now carries SPIRV-Tools' own LICENSE via the sed patch
above.