[SYCL][DOC] Adding design document for command graph extension

[reble]

This is an initial draft of our implementation design documentation.

[EwanC]

Some other things I think it'd be worth documenting. Could be done in this PR, or in a follow-up:

• Relationship with a handler for processing command-groups to use in a node - had to fix this for capturing of temporaries bug.
• Sub-graphs - we create an empty node as an implementation detail to marshal all the dependencies.
• breadth-first approach - Once #182 is merged we should write down that implementation detail.

[EwanC]

This is a good starting point.

Would also like to have sections with my previous suggestions, and also taking the comment content from

llvm/sycl/plugins/level_zero/pi_level_zero.cpp

Lines 8832 to 8889 in 452e7ae

	/* Command-buffer Extension
	The PI interface for submitting a PI command-buffer takes a list
	of events to wait on, and an event representing the completion of
	that particular submission of the command-buffer.
	However, in `zeCommandQueueExecuteCommandLists` there are no parameters to
	take a waitlist and also the only sync primitive returned is to block on
	host.
	In order to get the PI command-buffer enqueue semantics we want with L0
	this adapter adds extra commands to the L0 command-list representing a
	PI command-buffer.
	Prefix - Commands added to the start of the L0 command-list by L0 adapter.
	Suffix - Commands added to the end of the L0 command-list by L0 adapter.
	These extra commands operate on L0 event synchronisation primitives used by
	the command-list to interact with the external PI wait-list and PI return
	event required for the enqueue interface.
	The `pi_ext_command_buffer` class for this adapter contains a SignalEvent
	which signals the completion of the command-list in the suffix, and
	is reset in the prefix. This signal is detected by a new PI return
	event created on PI command-buffer enqueue.
	There is also a WaitEvent used by the `pi_ext_command_buffer` class
	in the prefix to wait on any dependencies passed in the enqueue wait-list.
	┌──────────┬────────────────────────────────────────────────┬─────────┐
	│ Prefix │ Commands added to PI command-buffer by PI user │ Suffix │
	└──────────┴────────────────────────────────────────────────┴─────────┘
	┌───────────────────┬──────────────────────────────┐
	Prefix │Reset signal event │ Barrier waiting on wait event│
	└───────────────────┴──────────────────────────────┘
	┌─────────────────────────────────────────┐
	Suffix │Signal the PI command-buffer signal event│
	└─────────────────────────────────────────┘
	For a call to `piextEnqueueCommandBuffer` with an event_list `EL`,
	command-buffer `CB`, and return event `RE` our implementation has to create
	and submit two new command-lists for the above approach to work. One before
	the command-list with extra commands associated with `CB`, and the other
	after `CB`.
	Command-list created on `piextEnqueueCommandBuffer` to execution before `CB`:
	┌───────────────────────────────────────────────────────────┐
	│Barrier on `EL` than signals `CB` WaitEvent when completed │
	└───────────────────────────────────────────────────────────┘
	Command-list created on `piextEnqueueCommandBuffer` to execution after `CB`:
	┌─────────────────────────────────────────────────────────────┐
	│Barrier on `CB` SignalEvent that signals `RE` when completed │
	└─────────────────────────────────────────────────────────────┘
	*/

But can write all that up in a follow-up PR.