* fix:(default-flatpaks): Missing notification for system flatpaks
This approach, while more fragmented, it's cleaner, as there is a clearer separation of root & non-root operations done by flatpak-setup service. This should probably increase security too (but I'm not the expert to talk seriously about that). It also gets rid of some non-harming error for /var data, can't remember it fully.
While it may be confusing for users that they have to type:
`systemctl status --user system-flatpak-setup`
instead of previous:
`systemctl status system-flatpak-setup`
It is something worth sacrificing for the important user-experience fix.
* feat(default-flatpaks): Add info about which flatpaks are installed & uninstalled in notification. Also implement notification enable/disable config support.
* feat(default-flatpaks): Add support for configuring notifications in recipe file
* fix(default-flatpaks): Formatting fixes
* fix(default-flatpaks): Fix "enabling" typo instead of "configuring" notifications
* chore(default-flatpaks): Remove unused yq command
* fix(default-flatpaks): There is no need for 2 double quotes
This allows us to ditch the state file concept, which only allows us to run flatpak-setup once. After that, you need to manually delete the state file (system & user-flatpak-configured) if you want to have new changes from flatpak-setup.
This is not ideal.
We do not have the luxury of Bazzite, which allows you to change the version of the setup in setup service to automatically start it again (that's what they do).
Instead, we will install & uninstall only those flatpaks which are not on the list, ditching the need to have version checking.
I incorporated some shell formatting fixes, thanks to shellcheck.net.
The only thing that doesn't work right now is installing flatpaks from install list when you have some flatpaks installed already. Grep -v doesn't work for some reason when piped with echo, I'm looking in how to fix this.
I'm also looking into potentially bringing automatic version adjustment whenever you change the flatpak list/repo if possible, to ensure that flatpak-setup service exits immediately if there are no changes, compared to running fully checking for updates.
