Two way compatibility between MODULE and CONFIG detection

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`](https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_PREFER_CONFIG.html) 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](https://github.com/MathiasMagnus/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 `$` 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](https://github.com/MathiasMagnus/CMake/tree/opencl-components) branch.
- OpenCL-SDK changes can be found [here](https://github.com/StreamHPC/OpenCL-SDK/tree/two-way-compat).
- The changes needed for each of the SDK components are also inside working branches signified by the options supplied to Test-FindOpenCL [here](https://github.com/MathiasMagnus/Test-FindOpenCL/blob/a5b7c001fe921c09100399581ef3a6127a1f653f/CMakePresets.json#L33-L46), 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.

Start with the proposed changes to FindOpenCL.cmake and the SDK's Package Config, then review the Test-FindOpenCL repository and its CMakePresets.json matrix. Compare the opencl-components, two-way-compat, and component working branches to identify the required cross-repository behavior. Done means both discovery paths expose the compatible targets and legacy variables across the tested platform and build combinations.

Written by the indexing model from the issue text.