Make OpenSYCL live at HEAD

Inspired by recent events (#765), (#766), (#709), I thought it would be a good idea to kick off a discussion related to upstream compatibilities for hipSYCL.

# Main Point
HipSYCL is currently built and tested against various versions of Clang/LLVM (11 - 14 at the time of writing). I feel like it would make sense to add something like a "weekly build" (because nightly is overkill for the amount of commits in this repo).

I also think that it would make sense to provide a clear "current main compatibility target", and potentially set that target to "upstream".

# Suggestions
* A weekly build could use the latest version of Clang/LLVM, ROCm, CUDA. This would help detect outdated/changed APIs early so that stable hipSYCL releases are viable with newer toolchains for longer.
* If I am not mistaken, the current linux CI pipelines all test against Ubuntu. This would probably not be a good choice for a build that tests against the latest versions of, well, anything :sweat_smile: A rolling release distro is probably wanted here, so that things like recent glibc, recent python etc are implicitly used.
* If upstream toolchains are used for the development branch of hipSYCL, backwards compatibility may become simpler to maintain if it just means disabling unsupported features for older toolchains.
* Instead of treating all toolchains equally, setting the "default" compatibility target for hipSYCL to upstream Clang/LLVM may provide a clearer way of handling backwards compatibility in general. Something like having the code feel like "this is my default code path, but if you use an older toolchain I have a bunch of macros ready to fall back to your older toolchain". Currently it feels more like "If you have this toolchain I'll do this. If you have that toolchain I'll do that". This makes it harder to decide whether to *ENABLE* new features or *DISABLE* old features.

# Potential Issues
While I *think* the changes required to keep things always upstream-compatible are manageable, but I may be completely wrong here :sweat_smile:
* CUDA seems to never change anything anyways, so probably not a lot of issues here.
* For the CPU backends, breaking changes in Clang/LLVM can be fixed in hipSYCL.
* The ROCm experience is horrible. Last time I checked, they used ancient LLVM versions and a codebase split across multiple codependent repos. Trivial fixes can take *forever* to be merged, since AMD is using different internal development branches than the ones on GitHub. Considering how many issues in hipSYCL complain about some kind of issue with ROCm, this may require an issue on its own.

# Related
* The Chromium project uses clang at ["known good revisions, bumped every two weeks or so"](https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/clang.md).
* Abseil [lives at HEAD](https://abseil.io/about/philosophy#upgrade-support).
* We are currently using upstream Clang and friends in [rules_ll](https://github.com/eomii/rules_ll). From our experience, bumping commits often (usually roughly weekly, sometimes more often thant that) actually rarely breaks builds. Most breaks are easily fixed with like 2 lines of code, since changes in LLVM are frequent, but small. Simply holding off on breaking version bump for a for a day or two is also often viable.
* #727 is potentially related.
* I read in various issues that there are plans to rework the CI infrastructure. Maybe it would be nice to keep track of that progress somewhere.

---

On our `rules_ll` side, we are currently using the "living at HEAD" approach for Clang/LLVM and CUDA, and will do whatever it takes to make it work with hipSYCL and ROCm :smiling_imp:

@illuhad @fodinabor I would love to hear your thoughts on this :heart: