Support Metal DLPack ndarray imports and byte offsets

[XXXXRT666]

Summary

This adds test coverage for importing Metal-backed DLPack arrays into nb::ndarray, including PyTorch MPS tensors.

It also exposes raw DLPack storage metadata for device-backed arrays:

• data_handle()
• data_offset()

nb::ndarray exports can now set DLTensor::byte_offset explicitly via a new trailing data_offset constructor argument. This lets producers represent views into opaque device allocations, such as Metal id<MTLBuffer> handles, without copying when the logical array starts after the beginning of the allocation.

Tests

• Added a mocked Metal DLPack import test.
• Added a real PyTorch MPS DLPack import test guarded by needs_torch_mps.
• Added CPU and Metal DLPack export coverage for nonzero byte_offset.

[XXXXRT666]

Added explicit DLPack byte_offset export support: nb::ndarray constructors now accept a trailing data_offset, with CPU/Metal tests covering nonzero offsets.

[XXXXRT666]

Addressed the latest review

[hpkfft]

Thanks.

I think it's helpful for module developers that this PR now uses the name byte_offset since DLPack is inconsistent--strides are measured in terms of the dtype but the initial offset is measured in terms of bytes.
Twenty years ago, the buffer protocol made the wiser choice of measuring strides in bytes.
Note, for example, in C++ (assuming typical IEEE floating-point types):

• sizeof(float) == 4
• sizeof(std::complex<float>) == 8
• alignof(std::complex<float>) == 4

so it's unnecessarily limiting to measure strides in terms of element size.
See test41_noninteger_stride() for an example of a slice that doesn't work with DLPack.