feat(python): Clarify interaction between the CDeviceArray, the CArrayView, and the CArray

[paleolimbot]

When device support was first added, the CArrayView was device-aware but the CArray was not. This worked well until it was clear that __arrow_c_array__ needed to error if it did not represent a CPU array (and the CArray had no way to check). Now, the CArray has a device_type and device_id. A nice side-effect of this is that we get back the view() method (whose removal @jorisvandenbossche had lamented!).

This also implements the device array protocol to help test apache/arrow#40717 . This protocol isn't finalized yet and I could remove that part until it is (although it doesn't seem likely to change).

The non-cpu case is still hard to test without real-world CUDA support...this PR is just trying to get the right information in the right place as early as possible.

import nanoarrow as na

array = na.c_array([1, 2, 3], na.int32())
array.device_type, array.device_id
#> (1, 0)

[danepitkin]

Great work!

[danepitkin]

Very cool!

[danepitkin]

Out of curiosity, are there enums that can be used here instead of values 1, 0? Or do we need to wait for DLPack support.

[danepitkin]

If there are enums, it would be nice to print the name (e.g. device_type: 1 (CPU))

[paleolimbot]

This was a bit of a rabbit hole but a very good rabbit hole. There's no enum, but there is an ABI-stable set of defines that I turned into one and the result is much better!

[danepitkin]

This function is called frequently after initialization. Is it worth allowing __cinit__ to set device type/id?

[paleolimbot]

I would like to move away from any arguments in __cinit__ in most cases because a user could theoretically call nanoarrow.CArray(...) and get very strange errors. They should really all be ClassName._construct() or something (but maybe in a future PR).

[paleolimbot]

Apologies for the two additional changes, but:

• After adding the DeviceType, it was pretty clear that the CDevice was never going to get a Device wrapper in not-Cython. Interacting with the device is something that mostly happens in the classes that live in Cython, and the only thing that anybody needs to know about it otherwise is to print it or know if it's the CPU or not. For the other classes there's some payoff to wrapping them in Python (better IDE documentation + completion, iteration time), but the Device doesn't benefit from any of those.
• The discussion in [Format][C++] Recommended/required value for ArrowDeviceArray.device_id int in case of CPU data arrow#40801 suggested that the device_id for the CPU device should be -1 instead of 0.