c: int128_t, uint128_t

[xushiwei]

No description provided.

[fennoai]

Review Summary

This PR adds 128-bit integer aliases (Int128T, Uint128T) via the new c/ng.go (sourced from github.com/qiniu/x/xgo/ng), adds WcharT = int32 to ctypes_unix64.go, registers int128_t/uint128_t in llcppg.pub, and bumps go.mod to go 1.23 with the new qiniu/x v1.18.3 dependency.

Verified locally:

• go build ./c/ succeeds on host (unix64) and GOOS=js GOARCH=wasm go vet ./c/ passes — the package compiles on both.
• go.sum checksums for qiniu/x v1.18.3 match the module and the imported ng.Int128/ng.Uint128 types exist at that version.
• Placing the 128-bit aliases in a build-tag-free file (ng.go) is the right call — they resolve on every platform, so the new llcppg.pub entries always have a target.

Performance: no concerns (compile-time type aliases only).
Security / supply chain: no concerns — dependency pinned to an exact version, checksums verified, no new runtime attack surface.

One completeness note is inline. Overall the change is small and well-targeted.

[fennoai]

This adds WcharT to unix64, so 32bit/windows/unix64 now all define it — but ctypes_wasm.go (wasip1 || js) still does not. llcppg.pub maps wchar_t WcharT platform-agnostically, so on wasm targets c.WcharT is undefined and any consumer (or generated binding) referencing it won't compile. This is a pre-existing gap that this PR partially closes; consider adding WcharT = int32 to ctypes_wasm.go as well to finish making it consistent across all platforms.