Use cases for backend interoperability

SYCL 2020 provides an optional interface for application scope interoperability with the native backend API, where different implementations can choose which classes to provide interoperability for. Backend specifications can also then define which classes should have interoperability for an implementation of that backend.

This leads to the question of which classes should to provide interoperability for, and the best way to answer this question is to derive it from the possible use cases of application scope backend interoperability.

The current use cases we have identified are:

* Interoperability at the SYCL DAG level, using host tasks to inject arbitrary C++ functions with backend specific API calls between SYCL commands, a typical example of this would be the oneDNN project (https://github.com/oneapi-src/oneDNN).
* Interoperability at the kernel level, using a kernel_bundle to create a SYCL kernel from a backend-specific source code or IR and running that via the SYCL runtime.
* Interoperability with graphics APIs, sharing memory objects between SYCL the native backend API in order to interoperate with a graphics API such as DirectX or Vulkan for post/pre-processing.

Does anyone know of other use cases for SYCL application scope backend interoperability that we've not considered here?

Review the SYCL 2020 application-scope backend interoperability interface and the three use cases listed in this issue: host tasks, kernel_bundle, and graphics API sharing. Identify any additional use cases and determine which backend classes they require; the issue is complete when the use-case list and corresponding interoperability requirements are documented.

Written by the indexing model from the issue text.