Inconsistent accuracy requirements for image_streams coordinate calculations

Section 8.2 of the spec leaves the relative error of addressing mode calculations undefined regardless of device, but the CTS imposes stricter requirements for certain image data types and non-GPU device types.
Using test_image_read_1d as an example, float image types use the following conditions to determine the stricter bounds (by setting offset to 0.0f to bypass the extra testing with address offsets):

```
if (!imageSampler->normalized_coords || imageSampler->filter_mode != CL_FILTER_NEAREST || NORM_OFFSET == 0
#if defined( __APPLE__ )
// Apple requires its CPU implementation to do correctly rounded address arithmetic in all modes
|| gDeviceType != CL_DEVICE_TYPE_GPU
#endif
)
offset = 0.0f; // Loop only once
```

but other types do this:

```
// If we are not on a GPU, or we are not normalized, then only test with offsets (0.0, 0.0)
// E.g., test one pixel.
if (!imageSampler->normalized_coords || gDeviceType != CL_DEVICE_TYPE_GPU || NORM_OFFSET == 0) {
norm_offset_x = 0.0f;
checkOnlyOnePixel = 1
}
```

The image data type and filtering mode should be irrelevant for the address calculation errors this is meant to address, and the non-float cases are overly strict for non-GPU devices. The __APPLE__ logic seems relevant to all cases and could be replaced with a command line option something like STRICT_ADDRESSES to allow overriding the default behavior if the implementation is expected to be correctly rounded.

Read Section 8.2 of the spec, then inspect the test_image_read_1d address-calculation conditions for float and other image types. Compare the normalized-coordinate, filtering, device-type, and Apple-specific branches. Done means the CTS behavior and spec requirements are reconciled, including a clear decision on any strict-address override.

Written by the indexing model from the issue text.