[REVIEW] Explicit stream argument for device_buffer methods

[harrism]

When reviewing #167 I realized that some of the complexity of that PR is a result of rmm::device_buffer() having a reference to a stream that it uses internally. This raised some concerns in my mind.

1. What if the stream no longer exists when rmm::device_buffer calls cudaMemcpyAsync in its copy constructor, resize, or shrink_to_fit? Error.
2. Possibly more important. If someone uses one of these operators, it’s not clear externally that it is asynchronous. If they then use the device buffer’s memory on a different stream without first syncing its internal stream, there’s a race condition. It’s not obvious that the user needs to call device_buffer::stream() to get that stream and then sync it.

I think it's more obvious for device_buffer asynchronous methods to take an explicit stream argument. (The exception is operator=, since it can't take a stream parameter).

This PR makes that change. Now, the stored _stream is only used by the destructor. To enable changing what stream is used for destruction, this PR also adds a new set_stream() method.

[jrhemstad]

This should also be tested with cuDF before merging.

[harrism]

@jrhemstad I tested cudf locally before I opened the PR. I will create a same-name branch PR in cuDF to do CI tests before merging.