[CI] Add AdaptiveCpp CI

[illuhad]

Adds AdaptiveCpp to CI. SYCL Academy solutions are built with the AdaptiveCpp generic JIT SSCP compiler, and executed with both OpenMP and OpenCL backends.

Currently, it rebuilds AdaptiveCpp with every workflow run. This could certainly be optimized with some caching/container usage. But since the build still takes below 10 minutes, I think it's good enough as is -- at least as a starting point.

I also had to relax the device selector in a couple of exercises. Currently e.g. the device discovery exercise fails if it cannot find an Intel GPU. In the CI system, there is no GPU, let alone an Intel GPU. With this PR, it prefers Intel GPU but then picks something else if there's no Intel GPU.
There are also a number of exercises that use gpu_selector_v without clear reason - I've migrated those to default_selector_v so that we can run them in CI.

Independently from CI, there is IMO value in ensuring that all solutions can be run on CPU too. In this way, people will be able to run them even if there are some driver issues with their particular GPU.

There's some script hackery to find and run all solutions. It would be better if we had a cmake-based mechanism here to run all targets or so.

Enqueuing_a_Kernel does apparently not currently work with AdaptiveCpp and Intel CPU OpenCL due to a disconnect between what AdaptiveCpp needs from printf and what OpenCL/SPIR-V guarantees. So I've disabled running this exercise on OpenCL.

Similarly, I've disabled the atomic reduction on OpenCL - there are some issues with float atomic add. Not sure if that's a problem in AdaptiveCpp or if Intel CPU OpenCL just doesn't support it (I guess AdaptiveCpp should check capabilities and use CAS loop as a fallback).

@EwanC - I had to disable the oneMath exercise since it causes build failure. Your PR (which checks whether oneMath is available) will probably fix this once merged.
Once we have the nice global flag to enable/disable oneMath that if statement should be removed. We could then just disable building oneMath exercises using e.g. a cmake flag in the workflow.

[EwanC]

LGTM, having some CI is better than nothing and we can make Issues to track follow-on work for creating an AdaptiveCpp artifact to reuse in the CI workflow and a CMake target to run all the executable.

@EwanC - I had to disable the oneMath exercise since it causes build failure. Your PR (which checks whether oneMath is available) will probably fix this once merged.
Once we have the nice global flag to enable/disable oneMath that if statement should be removed. We could then just disable building oneMath exercises using e.g. a cmake flag in the workflow.

Makes sense, I don't mind the ordering of merging this or my oneMath CMake PR first, the second PR will need to remove the TODO code either way but that should be straightforward.