Consider changing `urProgramGetFunctionPointer` to `urProgramQueryHasKernel`

E.g.

ur_result_t urProgramQueryHasKernel(ur_program_handle_t hProgram, const char *pKernelName, bool *pHasKernelRet);

Currently SYCL-RT only uses urProgramGetFunctionPointer to check whether a program contains a kernel, and doesn't use the actual value of the result. This is only implementable in the OpenCL adapter by using the undocumented clGetDeviceFunctionPointer extension function, and we would like to rely on fewer vendor extensions.

We could implement this simplified entry point in the OpenCL adapter using clGetProgramInfo.

We can't just rely on the UR_PROGRAM_INFO_KERNEL_NAMES query, because this query cannot be implemented in the CUDA and HIP adapters, since there's no way to get the name of all functions in a module. There are long-standing comments in these adapters suggesting moving the has_kernel query from SYCL-RT to PI/UR.

Also, returning the actual function pointer in a backend-agnostic way doesn't make much sense, so it's unlikely other users of UR could make use of the existing entry point. Instead, using native interop of the program and kernel objects can be used to get the underlying function pointer.

Start by tracing the existing urProgramGetFunctionPointer entry point through the OpenCL, CUDA, and HIP adapters, then review the related SYCL-RT usage and long-standing adapter comments. The work is done when a urProgramQueryHasKernel-style entry point can determine kernel presence without returning a function pointer or requiring the undocumented OpenCL extension, while remaining viable for the supported adapters.