cmeel-cddlib: Add version 0.94.13 - #4849

cddlib (double description method library, used for vertex/facet
enumeration of polyhedra) 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/cmeel-m4/cmeel-glpk: one has-sitelib=false
py3-none wheel holding only the shared library, headers, and 14
command-line tools (lcdd/scdd/fourier/etc.), no Python extension to
build per interpreter. Leaf dependency (requires_dist: cmeel only) -
no cmeel-* build-time dependency to resolve from this registry.

GPL-2.0-only per the real upstream COPYING text (the wrapper's own
pyproject.toml just says generic "GPL"; confirmed the actual tarball's
COPYING is the plain GPLv2 boilerplate, not v3). Re-scoped per
cmeel-m4/cmeel-glpk's finding: patching-and-licensing.md's GPL
procedure (the collect-gpl-sources job) is scoped to GPL components
pulled in from our own build environment (e.g. the manylinux image's
gcc), not to porting a project whose own upstream source happens to be
GPL - the real applicable check is the doc's ordinary two bullets
("wheel carries upstream LICENSE", "linked libraries' own licence reqs
met"), same as every other license in this repo so far.

Confirmed against the real published x86_64 wheel
(cmeel_cddlib-0.94.13-2-py3-none-manylinux_2_28_x86_64.whl, unzip -l)
that it ships no LICENSE/COPYING file at all - the same gap already
found and fixed for cmeel-m4/cmeel-glpk, present in the upstream
wrapper itself on every platform, not riscv64-specific. Checked the
wrapper's own tag v0.94.13.c2 directly (not its newer "cmeel" dev
branch, which has since bumped to a different upstream release,
0.94n, with slightly different CMakeLists.txt formatting) to confirm
ORIGINAL_VERSION="0.94m" is what the published 0.94.13 wheel actually
built against; cddlib's own 0.94m release tarball ships COPYING at its
top level (confirmed: tar -tzf cddlib-0.94m.tar.gz). This wrapper's
ExternalProject_Add(cddlib ...) 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 = <bin>/cddlib-prefix/src/cddlib, 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 - same
fix shape as cmeel-m4/cmeel-glpk; will send upstream too.

Verified against the real published x86_64 wheel that the actual lib
filename is libcdd.so (plus libcdd.so.0/libcdd.so.0.1.2) and that
dd_AValue is a real exported symbol (nm -D), rather than guessing
either. No architectural riscv64 concern: cddlib is portable C with no
SIMD/arch-specific code path.