Add numba-cuda as runtime dependency

[pentschev]

The new numba-cuda package is replacing the old numba.cuda module from the numba package, which is now unmaintained. We recently discovered issues with getting the CUDA context on the new r580 driver that are resolved simply by having numba-cuda installed, therefore make that as a required dependency.

[jameslamb]

Similar to rapidsai/ucxx#481 (comment) ... could we make these >=0.14.0,<0.19, to be compatible with both the current state of cudf the state its about to be in when rapidsai/cudf#19604 is merged?

Then tighten this to >=0.18.0,<0.19 once that cudf PR is merged?

[jameslamb]

Ok we talked about this in rapidsai/ucxx#481 (comment) and the answer was "no, not right now".

I'm ok with merging this as-is, thanks for the explanation.

[pentschev]

xref rapidsai/ucxx#481 (comment):

As a recap, we had to rollback numba-cuda version dependency twice before, immediately this is NOT acceptable IMO. I don’t know if you recall, here's how events unfolded:

1. First introduced dependency: rapidsai/ucxx@d3aa4a3
2. Rolled back: rapidsai/ucxx@0f5f99f
3. And rolled back again: rapidsai/ucxx@41fa142

Since this is a critical issue, that we’ve been seeing segmentation faults in both RAFT and RMM, I think we first need to go the safe route and make sure everything is back to normal, then we can update the pin to a newer version.

Let's play it safe here as well, once we're sure everything is fine with numba-cuda being installed, then we can try a new version and make sure nothing else breaks.

[bdice]

Small suggestion for consistency in naming across RAPIDS.

[pentschev]

Thanks all for the reviews.

Just for the sake of completeness here about #1531 (comment), Kyle agreed we should go forward with the current naming and fix with rapids-reviser later if needed. Therefore, I'm triggering an auto-merge.

[pentschev]

/merge