cuda.core.system: Add MIG-related APIs

[mdboom]

These APIs are required by dask-cuda.

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1916/
https://nvidia.github.io/cuda-python/pr-preview/pr-1916/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1916/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1916/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[rwgk]

Strong suggestion to move this comment into the docstring, mainly so that it appears in the online documentation.

[rwgk]

Generated with Cursor GPT-5.4 Extra High Fast

I did not check these findings manually. (Recently such findings have become generally highly reliable.)

---

1. High: cuda_core/cuda/core/system/_mig.pxi:126 uses self._handle inside MigInfo.parent, but MigInfo only stores self._device. Accessing device.mig.parent will raise AttributeError instead of returning the parent device.

2. High: the get_device_count -> device_count rename was only half-applied. cuda_core/cuda/core/system/_mig.pxi:176 still calls self.get_device_count(), and cuda_core/tests/system/test_system_device.py:745 still calls mig.get_device_count(). On any system that exercises the MIG path, both mig.get_all_devices() and the test will fail with AttributeError.

3. Medium: the MIG mode logic is inverted for normal callers. system.Device.get_all_devices() returns top-level NVML devices from cuda_core/cuda/core/system/_device.pyx:296, but cuda_core/cuda/core/system/_mig.pxi:46, cuda_core/cuda/core/system/_mig.pxi:67, and cuda_core/cuda/core/system/_mig.pxi:92 gate mode/pending_mode/setter on is_mig_device. That means device.mig.mode reports False and the setter raises on the parent GPU devices that actually own MIG mode, so the new API does not expose enabled MIG mode through the normal enumeration path.