Improve wording about the optionality of image types

[AnastasiaStulova]

Spec says the following about image types

The image2d_t, image3d_t, image2d_array_t, image1d_t, image1d_buffer_t, image1d_array_t, image2d_depth_t, image2d_array_depth_t and sampler_t types are only defined if the device supports images, i.e. the value of the CL_DEVICE_IMAGE_SUPPORT device query) is CL_TRUE.

where defined appears to be confusing since all those are reserved identifiers (https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#keywords) and therefore are always recognized by the implementations.

As a matter of fact, clang doesn't implement the optionality of images correctly as they are always available regardless the macro. The behavior is now being changed for OpenCL 3.0 only.

Could we change the wording to use supported instead? This will align better with other optional types e.g. doubles

The double scalar type is an optional type that is supported if the value of the CL_DEVICE_DOUBLE_FP_CONFIG device query is not zero. If this is the case then an OpenCL C 3.0 compiler must also define the __opencl_c_fp64 feature macro.

[bashbaug]

The difference is pretty subtle between defined and supported. Practically speaking, is there any difference between the two?

I do like the proposed consistency between the optional "image" and "double" types. I think I slightly prefer the phrasing for "doubles" rather than the phrasing for "images".