Update vcpkg OpenCL port to point here

[jenatali]

The vcpkg OpenCL port currently points to old commits of the OpenCL headers and the ICD loader. It should be updated to point to here. That will:

• Update it to current best practices for how to target OpenCL
• Pick up OpenCL 3.0 support in both the ICD loader and the headers

[MathiasMagnus]

@jenatali It is on my TODO list, but it's blocking on some other items. The SDK intends to update CMake dependence in a backwards compatible manner. Plans are detailed here which have already passed the headers repo and has slightly stumbled on ICD and CLHPP as they lack some crucial tests.

Once all the CI and CMake rework goes through (hopefully these efforts will be boosted in the coming month) I intend on updating the portfile.

[jenatali]

Great, thanks! We had someone who was tripped up because they built a CL sample, and then ran it, and it didn't get CLOn12 support, because vcpkg's port put an old OpenCL.dll next to their exe. I haven't looked closely to see if this SDK throws away the DLL, but at least having an updated version would prevent that problem.

[MathiasMagnus]

@jenatali I gave it a go some time ago, however I stumbled across vcpkg_from_github not supporting submodules. I requested this feature be implemented, however until it's not, the port will not become any simpler. It'll still require cloning from all the repos separately using the same tagged version.

As a workaround, this repo (like all other OpenCL ecosystem repos) could move to FetchContent or some similar capability (if we'd be willing to raise CMake version requirements, which I'd sooooo much like). FetchContent is CMake 3.11, it isn't a big jump for the SDK (it is for the other repos), and recursive behavior isn't even needed; the transitive submodules of every repo is only needed for testing, however the SDK doesn't intend on being a superproject for development purposes of the submodules themselves. (At least that was not the original intention.)

(On a larger scale, moving everything to FetchContent el al. would allow us to omit downloading deps we don't need. CMock is a submodule to Header for eg. but we only needed when building tests. Users wouldn't have to know in advance whether they'll want to build tests or not to perform a recursive clone or not. This is on our backlog, and I very much intend to do it, but currently other matters enjoy priority.)