[SYCL][HIP] Add interop header and devcie specialization

[npmiller]

Fixes #6635 for HIP.

Note that it does mean the HIP extension header must be included in user applications in order to get the correct specialization, as is done in the test:

#include <sycl/ext/oneapi/backend/hip.hpp>

[npmiller]

I don't think the test failure is related, that test is marked unsupported on HIP and has nothing to do with interop

[densamoilov]

@npmiller, is there any reason why sycl/ext/oneapi/backend/hip.hpp must be included for HIP backend but CUDA backend doesn't need sycl/ext/oneapi/backend/cuda.hpp?

Good concern from @densamoilov. I think we probably can define this specialization in backend.hpp header itself in the same way as it is done for other backends.

[npmiller]

There's pretty extensive discussions on what's going on for CUDA on this PR:

• [SYCL][CUDA] Fix get_native interop for device #6649

But essentially including the extension header is how specializations for the different backends is supposed to work. The only reason it's not for CUDA is that there are projects using it without the header AND we're planning on changing the CUDA interop interface at some point, so decided to hold off on fixing it to use the header until we're ready to update the interface as well. This is not currently the case for the HIP interop as far as I understand it.

[againull]

There's pretty extensive discussions on what's going on for CUDA on this PR:

• [SYCL][CUDA] Fix get_native interop for device #6649

But essentially including the extension header is how specializations for the different backends is supposed to work. The only reason it's not for CUDA is that there are projects using it without the header AND we're planning on changing the CUDA interop interface at some point, so decided to hold off on fixing it to use the header until we're ready to update the interface as well. This is not currently the case for the HIP interop as far as I understand it.

Thank you for clarification.