Update UR versions of piext*CreateWithNativeHandle entry points

[kbenzie]

The piext*CreateWithNativeHandle entry points have an additional parameter OwnNativeHandle which is missing from UR versions of these entry points. Additionally in intel/llvm#7196 a new piextQueueGetNativeHandle2 introduces another parameter int32_t nativeHandleDesc.

Additionally, the ur*CreateWithNativeHandle entry points do not currently provide any form of extensibility which could require ABI changes or additional entry points to be introduced in future.

As such, update all ur*CreateWithNativeHandle entry points to include a pointer to struct parameter, which pNext chaining abilities, while also enabling the OwnNativeHandle and nativeHandleDesc functionality with is already present in PI.

[smaslov-intel]

Note that ur*getNativeHandle also need to return nativeHandleDesc

[jandres742]

So we need OwnNativeHandle in all the CreateNativeWithHandle APIs. Below you can see the interfaces I have identified currently need this change, and some extra ones:

urMemCreateWithNativeHandle: needs
OwnNativeHandle

urKernelCreateWithNativeHandle: needs
Program
OwnNativeHandle
Draft PR: #434

urContextGetNativeHandle: needs
NumDevices
Devices
OwnNativeHandle
Draft PR: #433

[kbenzie]

Okay, these look reasonable to me. I do think that the bool OwnNativeHandle should exist in ur_<object>_native_handle_props_t structs for all the ur<Object>CreateWithNativeHandle entry points to enable pNext chaining.

[jandres742]

Okay, these look reasonable to me. I do think that the bool OwnNativeHandle should exist in ur_<object>_native_handle_props_t structs for all the ur<Object>CreateWithNativeHandle entry points to enable pNext chaining.

Thanks @kbenzie . Good idea. Please see #433.

[jandres742]

#433 merged for urContextGetNativeHandle.

#434 updated for urKernelCreateWithNativeHandle