Move wrap() methods for significant wrapper classes out of detail_::

[codecircuit]

I might not found it, but there seems no way to construct a non-owning cuda::stream_t object from a native cudaStream_t without using a function from the detail_ namespace. I think this would be useful to improve the interoperability with other libraries. We could add a usage example in stream_management.cu.

[eyalroz]

The relevant function is, indeed, in the detail_:: namespace: cuda::stream::detail_::wrap(). We also have cuda::event::detail_::wrap(). Do you think the wrap() functions should be outside the detail_ namespace?

[codecircuit]

Every function in a detail namespace is not part of the exposed library interface and usage outside of the library is discouraged.

I do not have a reference for that, but intuitively this is what I expect from a detail/internal namespace. This enables also changes within the detail namespace of the library without breaking user code.

[eyalroz]

@codecircuit : Well, if you interact with CUDA through the wrappers, you won't need to wrap any handles. But it's true that if you mix API wrappers code with other CUDA-related code, then you might. So I guess I can take the wrap() out of detail_.

[eyalroz]

@codecircuit : Please give v0.4.5-rc2 a spin...

[eyalroz]

Wait a minute though.

Do you think that the function for wrapping a stream handle should be all-low-level? i.e. take the device handle? Or should it take a device_t? And similarly, when wrapping something with more context, e.g. both a CUDA device, and a CUDA context for a driver-API stream - should I also take the lower-level handles or the device_t and the context_t? In the non-detail_ function I mean?