fix: wlr-services might not have started services when they are disabled

This can happen when the compositor exits, the services aren't stopped
in time, and they crash because they can't connect to wayland display.
This will make sure they get re-enabled on start of wlr-services. This
shouldn't be dangerous, because wlr-services is started just once, and
at worst if it was failing, it would get restarted 5 times and then
disabled, leading to maximum of 5*5*(count of wlr-services) restarts,
which is quite a lot, but not infinity :) Anyway wlr-services
shouldn't be crashing when configured properly (what if service
doesn't exist...?) so this shouldn't ever happen.

fix: waybar should require wayland-display

feat: add mew

chore: move modules to modules subfolder

fix: wayland display service, add x wayland display service

chore: update wlroots, dwl git versions

fix: python-lsp-server adapt to no toolchain

fix: missing module in ripgrep-all

chore: update rust packages and their deps

Remove iamb temporarily

Fix missing module

Fix missing module

fix: s/wlroots-0.18/wlroots

update

update

fix: git repos for ruther packages

feat: add forgejo

fix: wayland-display services

Except emacs, the services did not actually
need wayland-display, only dbus. For emacs,
wayland-display is required for stuff like xdg-open
to work.

fix: another arm none eabi fix

fix: missing new functions for arm none eabi toolchain