zero_sized_enqueue tests behavior contrary to OpenCL specification

Originally commented on https://github.com/KhronosGroup/OpenCL-CTS/pull/2378, but opening a new issue to make sure it does not get lost.

Although the spec includes "kernels executed over ranges of no work-items" as an example of a command that may be submitted and effectively do nothing, the spec for `clEnqueueNDRangeKernel` also still says:

> [clEnqueueNDRangeKernel](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#clEnqueueNDRangeKernel) returns [CL_SUCCESS](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_SUCCESS) if the rnel-instance was successfully queued. Otherwise, it returns one of the following errors:
> [...]
> [CL_INVALID_GLOBAL_WORK_SIZE](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_INVALID_GLOBAL_WORK_SIZE) if global_work_size is NULL or if any of the values specified in global_work_size[0], …​ global_work_size[work_dim - 1] are 0. Returning this error code under these circumstances is [deprecated by](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#unified-spec) version 2.1.

[The meaning of "deprecation"](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#_glossary) is:

> **Deprecation**
> Existing features are marked as deprecated if their usage is not recommended as that feature is being de-emphasized, superseded and may be removed from a future version of the specification.

My reading of this is that implementations are required to return an error for this. Applications should not rely on it being an error because a future version of OpenCL may change that, but that change has not yet been done, the 3.0 spec still says it's an error for now, and OpenCL CTS should not yet be testing that no error is returned.

---

Note: Although this came up as a failing test in our implementation, this did also uncover issues in our implementation where we have to make changes anyway. For practical reasons, we are currently planning on disregarding this part of the spec and doing what OpenCL CTS expects, and revisiting this and checking what further updates are required once either the spec or OpenCL CTS is updated.

Start with pull request 2378 and the clEnqueueNDRangeKernel specification text, then locate the CTS test covering zero-sized global work sizes. Compare its expected result with the current OpenCL 3.0 wording and the issue's interpretation. Done means the discrepancy has an agreed resolution reflected in the relevant CTS behavior or specification guidance.

Written by the indexing model from the issue text.