[FEA]: Support exporting `StridedMemoryView` objects via DLPack

[kkraus14]

Description

Add support for exporting StridedMemoryView objects via the DLPack protocol.

Requested Features

Both the following protocols should be supported:

1. __dlpack__ / __dlpack_device__ - The standard Python DLPack protocol for interoperability with frameworks like NumPy, PyTorch, JAX, CuPy, etc.

2. __c_dlpack_exchange_api__ - The C-level DLPack exchange API for efficient zero-copy data sharing at the C/Cython level.

Motivation

Currently, StridedMemoryView can consume DLPack-compatible objects, but it cannot export itself as DLPack tensors. Adding export support would enable it to be seamlessly passed to any library that accepts DLPack inputs, improving interoperability across the Python data science ecosystem.

Additional Context

• DLPack spec: https://dmlc.github.io/dlpack/latest/
• __c_dlpack_exchange_api__: https://dmlc.github.io/dlpack/latest/c_api.html#c.DLPackExchangeAPI
• Related to the ongoing discussions around StridedMemoryView design (#1371)

[leofang]

Not re-exporting was done on purpose, because if a downstream consumer can accept DLPack already, why don't they just take the input arrays directly instead of trampolining through SMV?

[kkraus14]

It's not about trampolining, but with the new constructors for SMV, i.e. from_buffer, there's more ways to construct an SMV and it's easier to use SMV conveniently as a return type in a downstream library and it would be nice to allow it to be passed around to other downstream libraries that haven't directly integrated with it.

For something concrete, say someone wanted to use cuda.core to allocate some memory using a custom memory resource and run some numba-cuda kernels against that memory via SMVs and then pass the resulting SMVs over to something like PyTorch.