[BACKEND] Added sycl backend support

[Sarbojit2019]

[Phase-1]

1. Change brings SYCL backend used in troch. This will help triton workloads get sync with torch.
2. Change is addressing open issue [FE]: Use SYCL runtime rather than L0 in Triton FE/driver #150

There is a phase-2 change planed which will cleanup / remove level-zero codes.

[Sarbojit2019]

Current error/failures look to me as environmental issues. @vlad-penkin @whitneywhtsang Can any of maintainer please confirm?

[whitneywhtsang]

Current error/failures look to me as environmental issues. @vlad-penkin @whitneywhtsang Can any of maintainer please confirm?

It is no longer failing with libmkl_sycl_blas.so.4, the new failure looks like

>       self.context = mod.init_context(torch.xpu.current_stream().sycl_queue)
E       ValueError: PyCapsule_GetPointer called with invalid PyCapsule object

/opt/hostedtoolcache/Python/3.9.18/x64/lib/python3.9/site-packages/triton/runtime/driver.py:792: ValueError

[Sarbojit2019]

Test failures are due to change in function signature between ipex1.13 vs ipex2.0. We should at least move to ipex2.0 soon.

ipex 2.0 https://github.com/intel/intel-extension-for-pytorch/blob/release/xpu/2.0.110/intel_extension_for_pytorch/xpu/streams.py#L17C43-L17C43

ipex1.13 : https://github.com/intel/intel-extension-for-pytorch/blob/release/xpu/1.13.120/intel_extension_for_pytorch/xpu/streams.py#L12

[whitneywhtsang]

Test failures are due to change in function signature between ipex1.13 vs ipex2.0. We should at least move to ipex2.0 soon.

ipex 2.0 https://github.com/intel/intel-extension-for-pytorch/blob/release/xpu/2.0.110/intel_extension_for_pytorch/xpu/streams.py#L17C43-L17C43

ipex1.13 : https://github.com/intel/intel-extension-for-pytorch/blob/release/xpu/1.13.120/intel_extension_for_pytorch/xpu/streams.py#L12

#239 moves ipex to 2.1.10.

[whitneywhtsang]

@Sarbojit2019 Now that #239 is merged, please rebase your PR.
A general comment, don't think we need to keep the old code IMO, as we can get a copy from git log if needed.

[kurapov-peter]

The PR needs some general cleanup, but I'd like us to explicitly articulate how we solve the problem and what are the next steps.

We bring in the sycl runtime, get the necessary handles from pytorch to queues, device, etc, and generate the same kernel/module via L0. Finally, we bundle the kernel into a "sycl program", create a sycl kernel and transfer the ownership to the sycl runtime. We then submit a sycl kernel to a sycl queue so that any consumer of the queue would be able to wait on the event in that queue (by querying outstanding events).

Could you please extend this with the phase 2 as you named it?

[kurapov-peter]

Also, a general question. Have we considered simply wrapping a level zero event handle into a sycl object and putting it into the queue? What is the downside of such an approach? In other words, why do we want to redo the launcher all everything instead?