fix: gate bindgen layout tests on 64-bit pointer width

[kylebarron]

Disclaimer: This was auto-generated by Claude, and I haven't looked at it yet.

---

Problem

The bindgen-generated src/ffi.rs emits struct size/offset layout tests
using the host pointer width (64-bit). On 32-bit targets these hard-coded
sizes underflow at const-eval and the crate fails to compile. This breaks, for
example, wasm32-unknown-emscripten (the Pyodide wheel target):

error[E0080]: attempt to compute `12_usize - 16_usize`, which would overflow
   --> src/ffi.rs:282  ["Size of DLPackExchangeAPIHeader"][size_of::<…>() - 16usize];
error[E0080]: attempt to compute `32_usize - 56_usize`, which would overflow
   --> src/ffi.rs:309  ["Size of DLPackExchangeAPI"][size_of::<…>() - 56usize];

Every pointer-containing struct (DLTensor, DLManagedTensor,
DLManagedTensorVersioned, DLPackExchangeAPIHeader, DLPackExchangeAPI) is
affected, since function/data pointers are 4 bytes on wasm32 vs 8 on x86-64.
The struct layouts are correct on 32-bit (#[repr(C)] follows the target C
ABI) — only the generated size assertions, baked in from a 64-bit host, are
wrong.

Fix

Gate every layout-test block on #[cfg(target_pointer_width = "64")], so the
checks still run where they were generated (64-bit) but no longer break 32-bit
builds. The bindgen post-processing in dlpark-bindgen is updated to reproduce
the gate on regeneration, and src/ffi.rs is updated to match.

Verification

cargo check -p dlpark --target wasm32-unknown-unknown   # was failing, now passes
cargo check -p dlpark                                   # 64-bit checks still run

🤖 Generated with Claude Code