Consider a variant of make_async_future which also receives a state

[jaredhoberock]

CUDA tasks created via external sources often have state that come along with them. It would be nice to turn such tasks into cuda::async_future<T>s instead of cuda::async_future<void>.

There are at least two use cases:

1. Create an async_future<T> with state, and hand over ownership of the T to the async_future<T>. The T gets destroyed and its memory deallocated with the future.
2. Create an async_future<T> with state, and retain ownership of the T. The T is not destroyed with the future.

Perhaps the right way to model use case 2. is with async_future<T&>? The asynchronous state carried around by the future would be a pointer to T, rather than a T itself. There might even be a way to avoid dynamic allocations entirely in this case.

[jaredhoberock]

Following from the above, there would be two different non-void overloads:

Owning version:

   // make a future<T> from this event, pointer, and deleter object.
   // the future owns ptr and deletes it using deleter
   // the caller is responsible for calling cudaEventDestroy() on e
   template<class T, class Deleter>
   async_future<T> make_async_future(cudaEvent_t e, T* ptr, Deleter deleter);

Viewing version(s):

   // make a future<T&> from this event and object
   // the future does not own the value, it is just a view of it
   // the caller is responsible for calling cudaEventDestroy() on e
   template<class T>
   async_future<T&> make_async_future(cudaEvent_t e, T& value);

   // make a future<const T&> from this event and object, as above
   // the caller is responsible for calling cudaEventDestroy() on e
   template<class T>
   async_future<const T&> make_async_future(cudaEvent_t e, const T& value);

Some foundational work needs to happen in async_future to make the above possible:

1. async_future needs to be taught about Deleters.
2. async_future needs to be taught about references.

[jaredhoberock]

For the owning version, it might be a better idea for make_async_future to receive a void* to emphasize that the buffer should be untyped, i.e., it should not point to an extant object.

[jaredhoberock]

On second thought, that last idea is wrong -- the pointer coming in should be typed because after the event is complete, a T value does exist at address ptr. The future doesn't need to placement construct the value in an untyped buffer.

[jaredhoberock]

Even though the state has already been allocated, it might be more straightforward for make_async_future() to accept an Allocator rather than taking a Deleter:

1. Allocators are probably more common in user code than are Deleters.
2. The underlying detail::asynchronous_state is implemented in terms of an Allocator rather than a Deleter.

It's possible to adapt an Allocator into a Deleter, but it's not possible to adapt in the other direction without an additional "Newer".