Turn resource adaptors into alias templates

[miscco]

Currently all resource adaptors are templated on their upstream resource.

Transitioning to resource_ref this is superfluous, as we do not need to know the upstream type anymore.

However, we cannot simply remove the template argument, as that would break user code. So we need to first introduce an indirection using an alias:

template<class>
struct resource_adaptor_impl{};

template<class Upstream>
[[deprecated("Use resource_adaptor_ref instead")]] using resource_adaptor = resource_adaptor_impl<Upstream>;

using resource_adaptor_ref = resource_adaptor_impl<int>;

[harrism]

I'm confused by the ref here, because I don't think this is intended to be a reference. Am I correct? Is the idea to make the alias match the name we intend the caller to eventually use?

[miscco]

The issue is how to transition something that is a template to something that is not. I am all ears on how to switch names

[harrism]

I don't have any ideas but answers to my questions might give me some. :) I still have the same questions I wrote above.

[harrism]

I think there's an easier way to make this change (though it will take at least 2 releases).

1. Create new (duplicate) adaptor classes (and factory functions as necessary) that don't have the upstream template parameter.
2. Convert downstream RAPIDS libs to use the new classes instead of the old ones.
3. Deprecate the old classes.
4. Remove the old classes.

[harrism]

My current plan is to:

0. Deprecate adaptor factories (done)
1. Add resource_ref constructors to the adaptors.
2. Add a new alias for each adaptor class as @miscco described in this issue. I suggest just drop resource from the name. e.g.

using logging_adaptor = logging_resource_adaptor_impl<device_memory_resource>;

3. Convert RAPIDS to use the new constructors and adaptor aliases.
4. Deprecate the old constructors and adaptors.
5. Rename the old adaptors to the new alias names. Remove the old constructors.

[bdice]

We need to revisit this task, as it would help with the transition to making RMM a shared library. Fewer template parameters would be better for a shared library, and having a CRTP-like structure with a known parent resource type does not present that many practical benefits.