Ensure the mempool wrapped behind `DeviceMemoryResource` can be customized

[leofang]

At the driver level, users are free to create as many cudaMempool_t as they like, because each pool could be configured differently. So the cuda.core semantics of dev.memory_resource reads: "Give me the memory resource that wraps the device's current (or default, if no one touches it) mempool." However, users can create a side DeviceMemoryResource instance wrapping a new instance of cudaMempool_t (say by passing a pool config or by wrapping a foreign cudaMempool_t pointer) and allocate from there, instead of from dev.memory_resource, just like how they could do the same at the C level with raw driver APIs. In fact, #446 demonstrates such a use case: Allocating a new mempool for IPC purposes.

Originally posted by @leofang in #717 (comment)

I think this has always been the intent but I realize we don't have a dedicated tracking issue.

[leofang]

We now have DeviceMemoryResourceOptions for customizing DeviceMemoryResource and likewise for other built-in MRs. Closing.