Two way compatibility between MODULE and CONFIG detection

[MathiasMagnus]

Ever since this SDK has cleared up some of the long-standing issues around the underdefinition of some SDK components (primarily the C++ headers) while also adding new functionality, two new CMake-related issues arose:

• People wanting to use the new features introduced in the SDK's Package Config have to explicitly opt-in via an all-or-nothing variable, CMAKE_FIND_PACKAGE_PREFER_CONFIG because CMake chose its default behavior in the name of compatibility, and the Find Module shipping with CMake always takes precedence.
• People finding the SDK via Package Config may still want to use the legacy variables defined by the Find Module. #85

The solution to these two problems lay in two different repos.

• The imported targets introduced by the SDK also need to be exposed by CMake's Find Module: FindOpenCL.cmake
• The SDK's Package Config needs to expose the same legacy variables which the canonical Find Module sets.

Proposed solution

The number of sensible ways to consume an OpenCL SDK explode almost combinatorically; almost because some combination of builds are not possible, or simply way too complicated to make it worthwhile supporting. The repository Test-FindOpenCL aims on exploring this phase space.

The repo tests Windows/Linux/MacOS with a myriad combinations of building and consuming all the different components. Sample projects are oblivious to the means of how each SDK component is supplied: provided from separate builds of each or in a unified fashion from an SDK build.

Some notable absentees from the matrix:

• Consuming the utility libraries using variables is not possible, as they are shipped as both debug and release binaries (especially important for the UtilsCpp.lib where the ABI changes. While adding the XYZ_DEBUG set of variables is possible, it makes matters particularly complicated when an SDK only ships one of them. If a project builds/installs all the components in Release, is that considered a complete installation? Should the Find Module reject such an install even if consumers are never interested in the Debug libraries?
• Windows builds have extra dependencies when the ICD Loader is built as a static lib. Those extra deps manifest as $<LINK_ONLY:xyz.lib> entries in INTERFACE_LINK_LIBRARIES, but augmenting the Find Module to try_compile a sample program and see if those deps (which may change in the future) are required is brittle and doesn't scale.
• Consuming the C++ headers via variables, as this was specifically one of the blind spots of the existing Find Module.

Notes

The proposed changes require a few changes not yet upstreamed, but hoping to land each and every one. The set of required changes can be found here:

• Upstream CMake changes required are in this branch.
• OpenCL-SDK changes can be found here.
• The changes needed for each of the SDK components are also inside working branches signified by the options supplied to Test-FindOpenCL here, most importantly
  • on Windows a fix for static builds of the ICD loader
  • on MacOS a fix for avoiding the inclusion of the system OpenCL framework headers, because they aren't compatible with opencl.hpp anymore.