Improve coverage of input data processing types in oneDPL unit testing with dpcpp backend

[danhoeflinger]

Capturing this comment as an issue:

Perhaps it makes sense to have a unit test targeted specifically at handling different input types and covering __get_sycl_range combinations using a simple lightweight API call and a device policy.

Originally posted by @danhoeflinger in #1413 (comment)

I would like us to improve our testing coverage by calling a simple API (like copy) with a variety of combinations of input types, USM data, sycl_iterators, host_iterators, reverse_iterators, fancy_iterators, nested fancy_iterators, to better catch issues in oneDPL's input data processing for dpcpp backend.

[danhoeflinger]

@SergeyKopienko, I'd like to get your take on this. If there already exists something like this, or if you have ideas on how this would best augment our current testing.