Add support for mocking to tests & test X11 struts

[Caellian]

This PR adds some very basic mocking capabilities to tests.

The goal of this PR is to test values set by set_struts.

Mocking was forced on me because set_struts calls XChangeProperty which obviously wouldn't work without X11 initialization code.

Mocking works by linking mocked methods before conky_core.

I added a basic system to allow retrieving mutations that mocked functions perform (e.g. defining atoms, XChangeProperty information, etc.).

[netlify]

✅ Deploy Preview for conkyweb ready!

Name	Link
🔨 Latest commit	992e67c
🔍 Latest deploy log	https://app.netlify.com/sites/conkyweb/deploys/675fbd9a86b45a000858657a
😎 Deploy Preview	https://deploy-preview-2115--conkyweb.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Caellian]

• I kept this line like this for a reason, it previously caused compilation to fail because alignment wasn't available to some file (wayland?) that uses it. Note to self to check before merge.

[Caellian]

While mocking would be great, I'm putting this off for now because Lua options are very difficult to mock the way they currently work. Constructor was the issue and a more data-oriented approach would greatly help.

However, the testing I did manage to run didn't indicate any issues so far and would only serve for regression testing.

The issues (#1917, #1961, #2112) likely come from how different WMs handle struts as there are some differences. To deal with that, conky would need to detect WM and use correct implementation at runtime.

New set struts documentation

/// Reserve window manager space
///
/// Both `_NET_WM_STRUT` and `_NET_WM_STRUT_PARTIAL` work in coordinates
/// relative to root window (or sometimes Xinerama/Screen).
///
/// Values tell the WM which regions of the screen are invalidated. So, a
/// `bottom` value of `30` means that the window reserves bottom 30px of the
/// screen.
///
/// Because struts aren't handled the best by all WMs when multiple screens are
/// used, horizontal struts (top, bottom) should be preferred because that
/// works well for most multi-screen (horizontal monitor stacking) setups.
/// See: https://gitlab.gnome.org/GNOME/mutter/-/issues/452
///
/// Different WMs handle this differently, some adhere to the spec, some don't.
/// Spec compliant (relative to root window edges):
/// - mutter, metacity, openbox, marco, xfwm
/// Non-compliant (relative to edges of xinerama/single monitor):
/// - compiz, kwin, i3, fluxbox
///
/// Article why KWin doesn't follow the spec:
/// https://blog.martin-graesslin.com/blog/2016/08/panels-on-shared-screen-edges/