[FEA]: `shared_ptr` that can be used in kernel code

### Is this a duplicate?

- [X] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this request and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)

### Area

libcu++

### Is your feature request related to a problem? Please describe.

I asked [around](https://stackoverflow.com/questions/78607024/does-the-cuda-standard-library-have-shared-ptrs-that-can-be-used-in-device-cod), but it I got a negative answer. My own search on this repo only showed `shared_ptr` being used in host code.

Basically, my problem is that I am working on a reference counting Cuda backend for [Spiral](https://github.com/mrakgr/The-Spiral-Language) and I am changing my mind that the ref counting work should be done by the Spiral compiler itself. If I had a `shared_ptr` class in kernel code I could compile recursive union types and various other data types so they use them. Right now, it'd be very easy to break the ref counting passes using macros, while `shared_ptr` would mesh well with those.

The intended purpose of this class would be specifically for data not being shared between threads. In other worse, for single threaded code.

One other motivation behind having this is to lower the compilation times taken by the Cuda compiler. Previously, I've created the NL Holdem game directly on the GPU and I suspect that making use of too many value types is making the compilation times increase exponentially.

### Describe the solution you'd like

`shared_ptr` in device code seems like a good solution.

### Describe alternatives you've considered

Currently I have my own ref counting pass in Spiral that was made for a C backend. Something like that would be the only choice in C and it makes sense there. It is also designed to play well with tail recursion. But so far, even though the Cuda compiler does support tail recursion, I had to rewrite the inner loop for the Leduc game into an imperative one as the tail recursive one kept stack overflowing, so that advantage doesn't matter there. Another issue with having an inbuilt ref counting pass is that the heap allocated types wouldn't be interoperable with C++ libraries. Again, this wouldn't matter with C as the language is too inexpressive to have libraries worth using, but C++ is different.

### Additional context

_No response_