OpenCL interoperability does not work on 64-bit OS

受影响的入口点位于 arrayfire/opencl.py 的第 88 行和第 156 行附近，以及该文件中其他使用 c_int_t 的位置。先阅读这些 ctypes 声明，然后复现 64 位 Windows OpenCL/PyOpenCL 设置；完成的标准是设备 ID 以及共享的设备、上下文和队列值不再溢出，并且互操作性正常工作。

Currently the OpenCL interoperability does not work on 64-bit Windows machine. The reason for this is the use of c_int_t which defaults to long on Windows (which on the other hand is 32-bit). This can be problematic with things like device IDs as they can easily go over 2^32/2-1. For example https://github.com/arrayfire/arrayfire-python/blob/master/arrayfire/opencl.py#L88 uses c_int_t, as well as a few other functions in the same file. This can be fixed by replacing the c_int_t with, for example, c_void_ptr_t as it is used with the context. Is there by the way some specific reason why context is treated differently?

There is also another issue. When the context is created by PyOpenCL, the input device, context and queue values are input as python ints in order to use the same context and queue, but on Windows you get <class 'OverflowError'>: int too long to convert errors then. These can be avoided by casting them to, for example, c_int64-types. For example in https://github.com/arrayfire/arrayfire-python/blob/master/arrayfire/opencl.py#L156, replace safe_call(backend.get().afcl_add_device_context(dev, ctx, que)) with safe_call(backend.get().afcl_add_device_context(ct.c_int64(dev), ct.c_int64(ctx), ct.c_int64(que))) (using c_void_p seems to work too).

I haven't tested these changes extensively, but they do seem to get things working on 64-bit Windows. I can provide a PR if needed.