Enhancement: Add clarification on use of dlpack for kDLOneAPI devices

[icfaust]

This has no functional impact on the header file, only to modify the text associated with the kDLOneAPI enum. It accomplishes two things:

• Fixes a spelling mistake with respect to partition
• Adds a small hint that the requisite memory allocation may have the necessary device information via the manager_ctx struct member.

While its clear that the manager_ctx is predominantly used for proper data deletion, it can also provide this necessary information associated with SYCL and/or OpenCL peculiarities (namely 'contexts' in both, but also specifically devices for SYCL, etc.). This should be done in the hope that various implementers of the __dlpack__ standard may try to additionally standardize the required additional information outside of dlpack.

Continues some discussion from #78

[icfaust]

It should be possible for the managing context to do the necessary SYCL runtime call to get the context (if needed by the consuming framework), leaving that possibility up to the generating framework. Either that or we should specify in the documentation that the default context should be used.

[leofang]

@oleksandr-pavlyk would you mind taking a look?

[oleksandr-pavlyk]

Thanks for fixing the spelling @icfaust .

How can consumer of data passed using DLPack protocol decide whether manager_ctx carries any additional information? Without answering this question the consumer must always call SYCL runtime to determine

1. map integral device_id to non-partitioned SYCL device (using sycl::get_devices()[device_id]))
2. determine whether USM pointer allocation is bound to a platform context for the platform containing that device using sycl::get_pointer_type
3. obtain the (possibly partitioned) SYCL runtime the allocation was made on using sycl::get_pointer_device

Even if the additional information intended to be stashed away in manager_ctx for kDLOneAPI device type is clearly documented as well as a mechanism to signal its availability, using manager_ctx to provide additional information about device allocation goes contrary to separation of concerns in design of DLPack: the DLPack struct is intended to describe the device allocation, and manager_ctx is intended for complementary purposes of managing lifetime of objects encoding information about device allocation.

Suppose the consumer has a way to determine that additional information is available in manager_ctx. To safely access it, one needs a header to describe the layout of data containing that information.

Perhaps a way to avoid a call to SYCL runtime is to expand DLDeviceType enumeration to introduce kDLOneAPI_{BackEnd}_{USM Type} for backends and USM types of interest (for example, those backends for which SYCL runtime provides interoperability layer).