Refactor the cuda_memcpy functions to make them more usable

[vuule]

Description

As we expanded the use of the cuda_memcpy functions, we realized that they are not very ergonomic, as they require caller to query is_device_accessible and pass the correct PAGEABLE/PINNED enum based on this.

This PR aims to make the cuda_memcpy functions easier to use, and the call site changes hopefully showcase this. The new implementation takes spans as parameters and relies on the host_span::is_device_accessible to enable copy strategies for pinned memory. Host spans set this flag during construction; creating a host span from a cudf::detail::host_vector will correctly propagate is_device_accessible. Thus, call can simply* call the cuda_memcpy functions with their containers as parameters and rely on implicit conversion to host_span/device_span. Bonus - there's no way to mix up host and device memory pointers 👍

Sharp edges:

• Conversion prevents template deduction, so calls that pass containers as parameters need to specify the template parameter (see changes in this PR).
• The API copies the min(input.size(), output.size()) bytes, as this is what we can do safely. This might cause surprises to users if they unintentionally pass spans of different sizes. We could instead throw in this case.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[bdice]

This might cause surprises to users if they unintentionally pass spans of different sizes. We could instead throw in this case.

Yes, this should be a runtime check and it should throw. If the caller wants to copy subspans, the caller can create subspans. Spans, as view types, are meant to make this easy.

[vuule]

Sure.
Just one thing to keep in mind for this use case:
host_span{my_hv.data(), subsize} is not the same as host_span{my_hv}.subspan(0, subsize) because the first one will not know if it's pointing to pinned memory.

[vuule]

done!