[SYCL] Fix issue of acquring kernel twice

[jzc]

In #11751, ref counting of kernels objects was changed to be more accurate in order to allow for in-memory caching to be disabled. When getting a kernel form the cache, the ref count the kernel handle is now incremented (when caching is enabled). Thus, a method like ProgramManager::getOrCreateKernel will increment the ref count of the kernel it gets. However, in enqueueImpKernel, when enqueuing a kernel with a kernel bundle,ProgramManager::getOrCreateKernel is called twice, first indirectly by:

llvm/sycl/source/detail/scheduler/commands.cpp

Lines 2527 to 2528 in c43a90f

	kernel SyclKernel =
	KernelBundleImplPtr->get_kernel(KernelID, KernelBundleImplPtr);

and second directly by:

llvm/sycl/source/detail/scheduler/commands.cpp

Lines 2538 to 2548 in c43a90f

	// When caching is enabled, kernel objects can be shared,
	// so we need to retrieve the mutex associated to it via
	// getOrCreateKernel
	if (SYCLConfig<SYCL_CACHE_IN_MEM>::get()) {
	auto [CachedKernel, CachedKernelMutex, CachedEliminatedArgMask] =
	detail::ProgramManager::getInstance().getOrCreateKernel(
	KernelBundleImplPtr->get_context(), KernelName,
	/*PropList=*/{}, Program);
	assert(CachedKernel == Kernel);
	assert(CachedEliminatedArgMask == EliminatedArgMask);
	KernelMutex = CachedKernelMutex;

This means that the ref count of the acquired kernel is incremented twice, yet the rest of the function will only free once, which leads to a leak of the kernel. As the second comment and asserts say, the only need for the second call to getOrCreateKernel is to fetch the mutex associated to the cached kernel retrieved from the first call, so this PR adjusts get_kernel to save this mutex and forgo this extra getOrCreateKernel call and unintentional additional ref count.

[steffenlarsen]

Looks reasonable to me! Should we have a note on getOrCreateKernel mentioning that it increments the reference count of the kernel?

[jzc]

@steffenlarsen Good idea, I added a comment about the ref count

[AlexeySachkov]

int-convert.cpp is a known issue on Windows, which was reported in #12011, I will proceed with merge for this PR