Add a fast path to copy to numpy.ndarray

[antonwolfy]

This PR adds a fast path to copy the USM data to numpy.ndarray.

In case when the USM data has the zero size, there is no need to synchronize the data and to perform the copy. It will be enough to call numpy.ndarray constructor with appropriate shape and dtype keywords.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?
• If this PR is a work in progress, are you opening the PR as a draft?

[github-actions]

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

[github-actions]

Array API standard conformance tests for dpctl=0.21.0dev0=py310h93fe807_53 ran successfully.
Passed: 1113
Failed: 8
Skipped: 119

[coveralls]

coverage: 85.895% (-0.003%) from 85.898%
when pulling 3db985f on add-fast-path-to-copy-zero-numpy-ndarray
into 6f6fe50 on master.

[ndgrigorian]

I wonder if we should still submit q.wait() for the sake of consistency. I doubt it would impact any workflows, but if one relies on this function to be a blocking call, it might be a surprise that it doesn't, even in this special case

perhaps we should also consider implementing asynchronous copies to NumPy and the blocking keyword, like CuPy does

[antonwolfy]

if one relies on this function to be a blocking call, it might be a surprise that it doesn't

But we never claimed that copying to a numpy array is a blocking call. It sounds more as the internal logic of dpctl, and the user has never to rely on it.

perhaps we should also consider implementing asynchronous copies to NumPy and the blocking keyword, like CuPy does

That sounds as a good idea which might be helpful to clear expose blocking logic under the user control.
But I would left that out of scope of that PR.

[ndgrigorian]

But we never claimed that copying to a numpy array is a blocking call. It sounds more as the internal logic of dpctl, and the user has never to rely on it.

True, but it might be expected regardless, since any transfer from device to host is expected to be a blocking call. But I guess it shouldn't really matter, since a size-0 array contains no data, so it probably shouldn't be an issue.