Add to_arrow_device() functions that accept views

[davidwendt]

Description

Adds the following new interop functions

unique_device_array_t to_arrow_device(cudf::table_view const& table, 
                                      rmm::cuda_stream_view stream,
                                      rmm::device_async_resource_ref mr);
unique_device_array_t to_arrow_device(cudf::column_view const& col, 
                                      rmm::cuda_stream_view stream,
                                      rmm::device_async_resource_ref mr);

Also refactors some common code with the ownership transfer version of these APIs.
And moves the to_arrow_schema() functions to a separate .cpp file.

Checklist

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

[vyasr]

Taking a peek while it's in draft (and rebased #15370 on these changes). Overall looks great here. I was originally hoping to unify the code paths a bit more, but the view path doesn't look all that verbose and it seems like it wouldn't improve readability much to unify. We could try implementing column equivalents of set_null_mask and set_view_to_buffer as class methods on the original to_arrow_device functor so that the operator specializations could be reused, but I don't really know how well that would work. WDYT?

[vyasr]

No longer relevant, see #15047 (comment)

[davidwendt]

Updated the comment. Let me know if I should just delete it.

[davidwendt]

Moved from to_arrow_device.cu

[davidwendt]

Moved to to_arrow_schema.cpp

[zeroshade]

is there a particular reason to do this vs passing them as parameters to the functors?

[davidwendt]

Just thought it was a bit cleaner since they are the same for every dispatch function.
Adding/removing parameters to every function got tedious.

[zeroshade]

Other than my nitpick and question, this seems good to me

[vyasr]

Some small feedback, but nothing worth blocking over except perhaps the release callback question. I worry that we're creating potential UB. I don't know if it's really specified explicitly anywhere in the spec, but throwing a C++ exception in a callback that may be called in C is definitely going to be implementation-defined behavior. Perhaps the best we can do is printing or logging the exception then returning safely? This feels like a hole in the spec that we should perhaps start a discussion about upstream.

[davidwendt]

/merge