api sub_group_dispatch checks incorrectly for CL_KERNEL_LOCAL_SIZE_FOR_SUB_GROUP_COUNT returning 0

The OpenCL specification does not guarantee that `CL_KERNEL_SUB_GROUP_COUNT_FOR_NDRANGE` returns the maximum sub group count when called with `[CL_DEVICE_MAX_WORK_GROUP_SIZE, 1, 1]`.

There exists hardware with more dynamic limitations.

One GPU or implementation could support multiple subgroup sizes (e.g. 32, 16 and 8) and a maximum of 1024 threads and 56 sub groups.

Calling `CL_KERNEL_SUB_GROUP_COUNT_FOR_NDRANGE` with 1024 threads would return 32 sub groups, because `16 * 56 < 1024` and `1024 / 32 == 32`, so a sub group size and count of 32 is the only way to fulfill that request.

But calling `CL_KERNEL_LOCAL_SIZE_FOR_SUB_GROUP_COUNT` with a subgroup count of 33 can return `528` because `16 * 33 == 528` or `264` because `8 * 33 == 264` as this is below the devices thread limitation.

I also don't see a requirement that `CL_KERNEL_SUB_GROUP_COUNT_FOR_NDRANGE` and `CL_KERNEL_LOCAL_SIZE_FOR_SUB_GROUP_COUNT` have to be consistent towards each other. So this behavior would be allowed by the specification and the test is too strict.

I see this behavior on my `Intel UHD Graphics 630` GPU and `rusticl`. For Intel's official stack this isn't a problem as they seem to limit the thread count to `256` and always assume a subgroup size of 8. There might be good reason for this behavior, but it still limits implementations to make full use of the hardware.

But sadly I couldn't really come up with a good way of changing this. We could test with `CL_DEVICE_MAX_NUM_SUB_GROUPS + 1` instead, but this requires OpenCL 2.1.

Locate the conformance test covering CL_KERNEL_LOCAL_SIZE_FOR_SUB_GROUP_COUNT and review how it checks results from CL_KERNEL_SUB_GROUP_COUNT_FOR_NDRANGE. Consult the OpenCL specification and verify that the test accepts all permitted implementation behavior without weakening the conformance requirement.

Written by the indexing model from the issue text.