Currently we have a handrolled MemoryPressureMonitor used only by the Linux ports WPE and GTK. Both ports already depend on GLib, which has its own GMemoryMonitor. We might as well depend on logic that is already available to us. Benefits:

 * The current code attempts to access /sys/fs/cgroup, but this will almost always fail because bubblewrap sandbox is now mandatory if not running inside flatpak, and this location is not accessible in either or bubblewrap and flatpak sandboxes
 * GMemoryMonitor has various backends including one that uses xdg-desktop-portal, escaping the above limitation
 * It can become smarter in the future without requiring changes in WebKit. E.g. there is a plan to switch from depending on low-memory-monitor to depending on systemd in https://gitlab.gnome.org/GNOME/glib/-/issues/2931
 * It's used by lots of applications rather than WebKit alone, and we don't have to maintain it

The downside is the GMemoryMonitor API currently does nothing if low-memory-monitor is not running. This should be available on all desktops nowadays, but might be missing on embedded devices. Having a fallback to our existing MemoryPressureMonitor wouldn't hurt. But this problem would also go away if GMemoryMonitor were to use systemd instead.