Fix IMAGE1D and IMAGE1D_ARRAY image type deduction in addImage

[bigmat18]

Fixes: #481

Description of Changes

Instead of guessing the image type from its dimensions, the Intercept Layer should explicitly query the exact memory object type by adding one more API call alongside the existing clGetImageInfo queries.

We can retrieve the type using clGetMemObjectInfo with the CL_MEM_TYPE flag, matching the existing coding style:

cl_mem_object_type imageType;

errorCode |= dispatch().clGetMemObjectInfo(
    image,
    CL_MEM_TYPE,
    sizeof(imageType),
    &imageType,
    NULL );

This guarantees that CL_MEM_OBJECT_IMAGE1D (and its array counterpart) remains exactly what the application requested, immune to driver quirks.

Testing Done

Tested on Windows

[bashbaug]

Thanks! Have you checked that the example you described on the issue generates the correct metadata now?

[bigmat18]

Yes, I tested with the same example and these are the results:
First allocation (desc1d.image_type = CL_MEM_OBJECT_IMAGE1D)

1024
1
1
16
16384
0
4318
4277
4340 // 0x10F4 that' s correct

Second allocation (desc1da.image_type = CL_MEM_OBJECT_IMAGE1D_ARRAY)

1024
5
5
16
16384
16384
4318
4277
4341 // 10F5 that' s correct

So it works as expected