Come up with plan for coupling between async_resource and resource concept

[jrhemstad]

Today, async_resource concept is a strict superset of resource which requires an async_resource to provide synchronous allocation APIs. This introduces a problem where you have to decide what stream to allocate on.

We should figure out what, if anything, we want to do about that, including decoupling async_resource and resource concepts.

We can close this issue when we have a plan on what we decide to do about this.

[jrhemstad]

@miscco synced with @harrism and RAPIDS is fine with decoupling the concepts since RAPIDS is only really interested in the async resources anyways.

The current plan is to just get #1637 merged by removing the sync from the deallocate and then worry about decoupling (if at all) later.

[harrism]

I think RAPIDS is probably interested in synchronous resources in certain situations, but I don't see a requirement to be able to use a single resource instance as both synchronous and asynchronous at the same time. So it seems fine to decouple.