May help us figure out unexpected incompatibilities in the future. While we still require C++14 or later, and may even upgrade to C++17 eventually, this should address some concerns about compatibility.
Plus it makes it easier to support things like Flatpak
The provided libobs-dev does not match CMake standards (LibObs instead of libobs like on all other platforms). It also does not provide the obs-frontend-api, or any other required files.
This splits the whole thing by the supported platforms to hopefully aid with future problem searching. While the combined script was nice, and allowed reducing the working overhead significantly, it also had collisions in what should have been defined.
Fixes several files incorrectly stated a different license from the actual project, as well as the copyright headers included in all files. This change has no effect on the licensing terms, it should clear up a bit of confusion by contributors. Plus the files get a bit smaller, and we have less duplicated information across the entire project.
Overall the project is GPLv2 if not built with Qt, and GPLv3 if it is built with Qt. There are no parts licensed under a different license, all have been adapted from other compatible licenses into GPLv2 or GPLv3.
A full clean build is only required for releases, so opting for iterative builds will speed up CI builds significantly. As we can re-use caches from across branches, opting for the first matching key, this means that any branch should re-use the closest match from the main branch.
Downside is that this may break if there is a change to the CMakeLists.txt file, since the project configuration is now different. Might be fixable, but that's not the aim of these changes.
There's no need to split by configuration type on proper generators, which slightly speeds up the build. Downside is that we can't get builds for both Debug and RelWithDebInfo - though we only need the latter anyway.
Builds on Ubuntu incorrectly used gcc instead of g++ for C++ building, resulting in files that should never have worked. Switching this to g++ should drastically improve the stability of StreamFX on Linux.
Also on MacOS we use Homebrew to install the remaining tools, but failed to correctly install a specific version of it. As Homebrew only installs the latest version of a package to the global search path, this adjustment should fix the issue with clang-format.
Finally since I was already at it, I added clang-tidy integration and made the clang integration global. This way it does not need to be called on a per-project basis any more.
While the system helped users get started quickly, it also presented a unique problem by itself. As CMake grew, the code that supported this system became more and more fragile to the point of failing at random, with no indication of why it would fail. Additionally as OBS Studio 28.0 adopted a much nicer system, it is no longer necessary to have this system at all.
As an addition to this change, all systems that could rely on FindModules now do so. This drastically reduces the complexity of the CMake system, while allowing significantly more flexibility with what binaries are really being used. In the best case this should allow a prepared user to build StreamFX by itself within seconds.
The runners "windows-2022" and "windows-2019" both come with almost identical software, and we can still target Windows 10 21H2. The same goes for "macos-12", "macos-11" and "macos-10.15", where we can simply target 10.15 and get the same result. Only Ubuntu does not make it easy, as it doesn't easily allow targeting a certain OS version.
There is no point in completely separating these, as CMake can build out-of-tree just fine. Thus we can reduce the overall complexity significantly, and also detect far more problems ahead of time. As a side bonus, we get both debug and release packages in one go.
