Table entry in cl_intel_split_work_group_barrier is too big

[Kerilk]

Documentation build errors on out/pdf/extensions.pdf with:

asciidoctor: ERROR: the table cell on page 180 has been truncated; Asciidoctor PDF does not support table cell content that exceeds the height of a single page

The offending SPEC is here:

OpenCL-Docs/extensions/cl_intel_split_work_group_barrier.asciidoc

Lines 104 to 133 in 6191cbe

	| For these functions, if any work-item in a work-group arrives at a barrier, behavior is undefined unless all work-items in the work-group arrive at the barrier.
	If any work-item in a work-group waits on a barrier, behavior is undefined unless all work-items in the work-group wait on the barrier.
	If a barrier arrive function is inside of a conditional statement and any work-item in the work-group enters the conditional statement and arrives at the barrier, behavior is undefined unless all work-items enter the conditional and arrive at the barrier.
	If a barrier wait function is inside of a conditional statement and any work-item in the work-group enters the conditional statement and waits on the barrier, behavior is undefined unless all work-items enter the conditional and wait on the barrier.
	If a barrier arrive function is inside of a loop and any work-item arrives at the barrier for an iteration of the loop, behavior is undefined unless all work-items arrive at the barrier for the same iteration of the loop.
	If a barrier wait function is inside of a loop and any work-item waits on the barrier for an iteration of the loop, behavior is undefined unless all work-items wait on the barrier for the same iteration of the loop.
	Behavior is undefined if a work-item waits on a barrier before arriving at a barrier.
	After a work-item arrives at a barrier, behavior is undefined if the work-item arrives at another barrier before waiting on a barrier.
	After a work-item waits on a barrier, behavior is undefined if the work-item waits on another barrier before arriving at a barrier.
	The `intel_work_group_barrier_arrive` and `intel_work_group_barrier_wait` functions specify which memory operations from before arriving at the barrier must be visible to work-items after waiting on the barrier by using the _flags_ and _scope_ arguments.
	The _flags_ argument specifies the memory address spaces to apply the memory ordering constraints.
	This is a bitfield that can be zero or a combination of the following values:
	`CLK_LOCAL_MEM_FENCE`: for `local` memory accesses. +
	`CLK_GLOBAL_MEM_FENCE`: for `global` memory accesses. +
	`CLK_IMAGE_MEM_FENCE`: for image memory accesses, for this flag the value of _scope_ must be `memory_scope_work_group` or behavior is undefined.
	The _scope_ argument describes the work-items to apply the memory ordering constraints.
	If no _scope_ argument is provided, the _scope_ is `memory_scope_work_group`.
	If the _flags_ argument differs between the barrier arrive function and the barrier wait function then only memory operations for the address spaces specified by the intersection of the two _flags_ arguments must be visible.
	If the _scope_ argument differs between the barrier arrive function and the barrier wait function then the memory ordering constraints only apply to work-items described by the narrower of the two _scope_ arguments.
	For each call to these functions, the values of _flags_ and _scope_ must be the same for all work-items in the work-group.

In practice if using a parallel build it is not an issue, since all pdfs will be built either way. The entry in the table gets truncated.

If using a serial build, following pdfs will not be built, and build has to be rerun which will finish building the remaining pdfs (since out/pdf/extensions.pdf has been built even with the error).