feat(cuda): bundle + auto-link the glibc≥2.38 isoc23 link shim

[NicolasRouquette]

On glibc ≥ 2.38 (Ubuntu 24.04, Fedora ≥ 38, Debian 13, recent EL9, …) the strto*
family is redirected to __isoc23_strto* under _GNU_SOURCE, which nvcc's host pass
forces. nvcc-compiled host objects then reference __isoc23_strtoull/etc.; when the
final executable is linked against an older glibc than nvcc compiled with — the case
whenever the Lean toolchain bundles a pre-2.38 glibc — those symbols are undefined and
the CUDA link fails:

ld.lld: error: undefined symbol: __isoc23_strtoull

This bundles a tiny object (csrc/cuda/common/torchlean_isoc23_shim.c) that defines
the four referenced names as weak wrappers over the plain strto* (declared
directly, so the file itself skips the C23 redirect), and compiles + links it
automatically into the CUDA build via a Lake target in the NN library's moreLinkObjs
— only when -K cuda=true. No -K flag or user-supplied object path is needed.

The symbols are weak, so a link-time glibc that already exports the real
__isoc23_strto* takes precedence, and the shim is inert on hosts whose objects never
reference these names (older glibc; and non-CUDA builds, which stay byte-for-byte
unchanged since the object is only linked under -K cuda=true). A
-Wl,--defsym=__isoc23_strtoull=strtoull alias does not work: lld resolves the
defsym target among defined symbols, but the C23 redirect leaves nothing referencing
the plain strtoull, so lld reports symbol not found: strtoull — a real definition is
required.

Verified: a -K cuda=true build (no extra flags) links cleanly and runs the full CUDA
test suite on Ubuntu 24.04 (glibc 2.39); without the shim the same build fails at link
with the undefined __isoc23_strtoull. This also unblocks #10 (its byte-cap parses
TORCHLEAN_CUDA_CACHE_CAP_BYTES with strtoull, hitting the same reference) on
glibc ≥ 2.38.

[Robertboy18]

Thanks, Nicolas — this looks good to me. Since main has changed around the Lake/native backend configuration, this PR now has a merge conflict. Could you rebase it onto the latest main and adapt the shim linking to the current setup? Once the CUDA build and tests pass again on glibc ≥ 2.38, we should be ready to merge this.