[FEA] Support memory resources from CCCL 3.2

[bdice]

Is your feature request related to a problem? Please describe. Recently, RAPIDS/CCCL nightlies began failing due to a change in CCCL's memory resources. See https://github.com/NVIDIA/cccl/pull/5313

Describe the solution you'd like RMM should support CCCL’s new memory resources, which are targeting CCCL 3.2. RAPIDS is currently using CCCL 3.1.

[bdice]

Current plan for adoption:

Allocation Interfaces

This list of tasks requires CCCL 3.1+, so we can ship these changes in 25.12.

1. Build RMM w/ 3.1 via polyfill and allocate updates (#2017) (25.10)

• Need to verify that all of RAPIDS builds with CCCL 3.1 with these changes in RMM, and ask Spark to do testing with the same pre-release of CCCL 3.1. The goal is to unblock adoption of CCCL 3.1 for RAPIDS.
• Then hopefully CCCL+RAPIDS CI should work.

2. Update polyfill to new allocate signature (RMM internal refactoring) #2112 (25.12)
3. Refactor RAPIDS to use new allocate signature #2126 (25.12)
4. Deprecate old allocate signature #2128 (25.12)
5. Remove deprecated legacy allocate interfaces #2150 (26.02)

Memory Resource Handling

This list of tasks requires CCCL 3.2+, so we will need to work on that migration in 26.02.

1. Implement a bridge for pointer-based resources https://github.com/rapidsai/rmm/issues/2143 (26.02)
2. Upgrade RAPIDS to use CCCL 3.2. (26.02)
3. Adopt any_resource in device-resource global mapping (26.02)
4. Adopt any_resource in custom containers (26.02)

• Things storing RMM resource_refs should instead store cuda::mr::any_resource
• Most of these changes will be in RMM, but there are some RAPIDS libraries with custom containers
• Start with rmm::device_buffer

5. Deprecate pointer-based resources (26.02)
6. Remove pointer-based resources (26.04)

[bdice]

CCCL 3.1.0 + RAPIDS 25.10 CI is working, and RAPIDS is nearly ready to adopt the new CCCL version in 25.12. This will complete task (1) above.