core: add integration testing utilizing QEMU via runNixOSTest

[PaideiaDilemma]

This is partially copied from hyprland's vm tests.

TODO:

• Add one or more comprehensive configurations for testing all widgets and their features
• Instead of sending SIGUSR1 to unlock, send a password via machine.send_chars

[PaideiaDilemma]

Within the new tests folder there are currently no standalone tests.
Just configurations and a waitForLock program. This program is used within the testScript in nix/tests/default.nix to wait until the session is locked.

In contrast to Hyprland, hyprlock doesn't have any ipc or other interactive parts that could be tested in a similar way to what "hyprtester" does.
Thus I decided against writing a cpp program that asserts stuff.

The test system instead launches each configuration in the test folder within hyprland running in a VM.
From the host, we unlock each configuration by sending characters through QEMU.
If we successfully lock and hyprlock returns exit code 0, the test case was successful.
Each configuration produces a log and a trace artifact.

In the future we could use apitrace diff or apitrace diff-images to assert visual behavior in some way.
The logs are the other avenue we have to further assert stuff.

Open questions:

• In the current version, does it even make sense to have the -DTESTS switch for including the CMakeLists.txt in the test folder?
• Why is is only running ~30 fps in the github runner but the full ~60 on my local machine. Is it because verbose logs are too much or is it or does the runner hit it's limits?

@fufexan some nix stuff I wanted to check with you. Let me know if you think any of the following points should be done differently.

• It uses hyprland from nixpkgs to avoid adding it as a flake input.
• I added a hyprlock-debug overlay that also contains this hyprlock-test-meta package (build from the tests folder), which is used within the vm test.
• I tried to follow the stuff you did in hyprland regarding the github workflow setup for nix.

[PaideiaDilemma]

i didn't even think about quotas tbh.
currently the tests take 3 min. will that be fine?

[fufexan]

• It uses hyprland from nixpkgs to avoid adding it as a flake input.

I believe it's fine. If you need the latest you could fetch the overlay with pkgs.fetchFromGitHub only for the test. This way we don't pollute the flake input tree with another useless copy of hl (for the end users).

• I added a hyprlock-debug overlay that also contains this hyprlock-test-meta package (build from the tests folder), which is used within the vm test.

LGTM

• I tried to follow the stuff you did in hyprland regarding the github workflow setup for nix.

That's fine. nix build is the only thing needed.

currently the tests take 3 min. will that be fine?

sure, afaik the Hyprland tests run about 10m due to rebuilding hyprland (not sure why, our store cache might be misconfigured).