[SYCL][DOC] Describe process of prototyping KHR extensions

Author: AlexeySachkov

sycl/doc/developer/KHRExtensions.md

@@ -0,0 +1,46 @@
+# Considerations for working on KHR extensions
+
+SYCL specification evolves through embedding extensions developed by various
+vendors, including Khronos Group itself (`khr` extensions).
+
+In order for a KHR extension to be accepted, there must be CTS tests for it and
+at least one implementation which passes them.
+
+Considering that KHR extensions are being developed in public, we can start
+prototyping them as soon as corresponding PR for an extension is published at
+KhronosGroup/SYCL-Docs.
+
+However, we shouldn't be exposing those extensions to end users until the
+extension if finalised, ratified and published by Khronos - due to risk of an
+extension changing during that process and lack of the officially published
+version of it.
+
+So, we can have a PR but can't merge it. Keeping PRs opened for a long time is a
+bad practice, because they tend to get stale: there are merge conflicts,
+potential functional issues due to the codebase changes, etc.
+
+In order for us to avoid stale PRs, all functionality which is a public
+interface of an "in-progress" KHR extension, must be hidden under
+`__DPCPP_ENABLE_UNFINISHED_KHR_EXTENSIONS` macro. That way we can merge a PR to
+avoid constantly maintaining it in a good shape, start automatically testing it
+but at the same time avoid exposing incomplete and/or undocumented feature to
+end users just yet.
+
+"in-progress" KHR extension term used above is defined as:
+- KHR extension proposed to Khronos Group which has not been published in a
+  released revision of the SYCL specification (of any version).
+
+  Note: merge of an extension proposal PR into KhronosGroup/SYCL-Docs repo is
+  **not** considered to be a publishing event. The extension specification has
+  to be available on the Khronos SYCL Registry website:
+  https://registry.khronos.org/SYCL/
+
+- Published KHR extension, which hasn't been fully implemented by us
+
+The macro is **not** intended to be used by end users and its purpose is to
+simplify our development process by allowing us to merge implementation (full
+or partial) of the aforementioned extensions earlier to simplify maintenance and
+enable automated testing.
+
+Due to this reason, we are not providing a separate macro for each "in-progress"
+KHR extension we may (partially) support, but just a single guard.