Conformance test_thread_dimensions.c extremely slow in for big CL_DEVICE_MAX_WORK_ITEM_SIZES

If the return value from the query CL_DEVICE_MAX_WORK_ITEM_SIZES is large, then the loops of the form

```c
while ((local_x_size > 1) && (final_x_size%local_x_size != 0))
local_x_size--;
```

are extremely slow.

The problem those pieces of code try to solve is to set local_size to be the maximum number smaller than the current local size which divides final_size.

A worst case scenario in such a case, which does seem to happen, is where final_size=1 and local_size is set to INT_MAX as it is what is returned by the query CL_DEVICE_MAX_WORK_ITEM_SIZES.

A naive improvement that helps speed up things enough for the test to be usable is to set local_size to be the minimum between it and final_size before starting the loop.

Delegating the procedure to a function also seems more reasonable

For example:
```c
cl_uint max_number_smaller_than_a_that_divides_b(cl_uint a, cl_uint b) {
if (a >= b)
return b;

while ((a > 1) && (b%a != 0))
a--;

return a;
}

```

and then replacing the loops with something like so
```c
local_x_size = max_number_smaller_than_a_that_divides_b(local_x_size, final_x_size);
local_y_size = max_number_smaller_than_a_that_divides_b(local_y_size, final_y_size);
local_z_size = max_number_smaller_than_a_that_divides_b(local_z_size, final_z_size);
```

Start in test_thread_dimensions.c and locate the loops adjusting local_x_size, local_y_size, and local_z_size after CL_DEVICE_MAX_WORK_ITEM_SIZES is queried. Check the surrounding thread-dimension tests, then verify that large queried sizes no longer cause excessive looping while the selected local sizes still divide the final sizes.

Written by the indexing model from the issue text.