[libcu++] Add resource_cast and dynamic_resource_cast

[pciolkosz]

This PR adds resource_cast and dynamic_resource_cast wrapper for internal __any_cast and __dynamic_any_cast specialized for resource wrappers.

I also added validation to __dynamic_any_cast implementation, which was right now succeeding regardless of what the destination interface was. Now it confirms destination interface is a subset of the original vtable. Tests were added to __basic_any testing to confirm this behavior

[bdice]

I did a bit of comparison between #8269 and this PR.

• Concept constraints. Add public any_cast for type-erased memory resources #8269 constrains every overload with resource_with / synchronous_resource_with. This PR's resource_cast is unconstrained, any _Tp is accepted. I wonder if this should be a compile-time error for types that don't satisfy the resource concept.
• Does this PR have enough Doxygen? Add public any_cast for type-erased memory resources #8269 has a bit more, I'm not sure what is expected.
• Test gaps compared to Add public any_cast for type-erased memory resources #8269:
  • nullptr input (covered by __any_cast internally, but seems untested in the public API)
  • moved-from wrapper returns nullptr
  • I'd like explicit tests that succeed or fail for derived-to-base casts, we have lots of MR inheritance in RMM
• Naming. cuda::mr::any_cast mirrors std::any_cast. Does this function have similar semantics to std::any_cast?

[pciolkosz]

Concept constraints. #8269 constrains every overload with resource_with / synchronous_resource_with. This PR's resource_cast is unconstrained, any _Tp is accepted. I wonder if this should be a compile-time error for types that don't satisfy the resource concept.

I added static_asserts inside

Does this PR have enough Doxygen? #8269 has a bit more, I'm not sure what is expected.

I think its fine

Test gaps compared to #8269:
nullptr input (covered by __any_cast internally, but seems untested in the public API)
moved-from wrapper returns nullptr
I'd like explicit tests that succeed or fail for derived-to-base casts, we have lots of MR inheritance in RMM

Added test cases

Naming. cuda::mr::any_cast mirrors std::any_cast. Does this function have similar semantics to std::any_cast?

I think because we also have the dynamic_resource_cast that has no equivalent in stl and the interface is restricted only to specifically resource wrappers I would stay with cuda::mr::resource_cast and cuda::mr::dynamic_resource_cast

[github-actions]

🥳 CI Workflow Results

🟩 Finished in 1h 20m: Pass: 100%/108 | Total: 1d 01h | Max: 57m 36s | Hits: 99%/281525

See results here.