[UR] Add handles to opencl adapter

[RossBrunton]

No description provided.

[RossBrunton]

This was from oneapi-src/unified-runtime#1176 . It flagged up some issues in LLVM which needed to be fixed (which they have now been).

[aarongreig]

rather than allowing Queue to be null I think we should query it out of Event here, otherwise we're introducing a regression when you query EVENT_INFO_QUEUE for an event created from a native handle since the implementation for that query just returns hEvent->Queue

[aarongreig]

actually that doesn't work because the query should return the corresponding ur handle not the native one, not sure what to do about this but it is a regression

[aarongreig]

could do fewer atomic accesses here

Suggested change

	size_t refCount = hContext->getReferenceCount();
	// ExtFuncPtrCache is destroyed in an atexit() callback, so it doesn't
	// necessarily outlive the adapter (or all the contexts).
	if (refCount == 1 && cl_ext::ExtFuncPtrCache) {
	cl_ext::ExtFuncPtrCache->clearCache(clContext);
	}
	if (hContext->decrementReferenceCount() == 0 ) {
	// ExtFuncPtrCache is destroyed in an atexit() callback, so it doesn't
	// necessarily outlive the adapter (or all the contexts).
	if(cl_ext::ExtFuncPtrCache) {
	cl_ext::ExtFuncPtrCache->clearCache(clContext);
	}
	delete hContext;
	}

[aarongreig]

we don't report exp features via extension any more

[EwanC]

I'd prefer if we could avoid creating a cl_event if the user hasn't passed a phEvent, this is the kind of in-order queue use-case there's an effort to optimize DPC++ for at the moment.