Please don't move processes out of cgroups

Hello! I just happened to be looking this project (considering it for inclusion into GNOME OS), and was surprised to find code that does things like:

- matching processes by their literal process name
- ripping processes out of systemd's cgroup management heirarchy and into bespoke .scope units

This _will_ break lots of things in various ways that aren't immediately obvious. I'll give a few examples:

- systemd's cgroups are structured to allow power management decisions to take place. For instance, background services are placed in a special background.slice so that resource limits can be applied to it. lpmd rips these processes out of these heirarchies, so the units end up in the generic app.slice and don't get the system's resource usage policies applied correctly
- systemd-oomd operates on the assumption that it can safely kill an app by killing the app's cgroup. lpmd moving individual processes out of the cgroup without the app's consent violates that assumption and will subtly break the system's OOM management (where apps will not get cleanly OOM killed as intended)
- I would consider lpmd moving processes out of systemd's configured cgroups and into its own a security vulnerability: the cgroup heirarchy enforces things like memory usage limits, CPU time limits, etc. If a system administrator configures such limits for security reasons (to prevent untrusted code from DOSing the system, for example), intel-lpmd moving that process out of that management heirarchy allows it to escape those restrictions. Absolutely nothing prevents malicious code (isolated in a container, for instance) to name its process "pipewire" and then magically get moved out of the restricted cgroup that's supposed to contain it.

I also heavily question some of the decisions made in lpmd's config file listing services by process name. For instance, `gdm-session-worker`, `gdm-wayland-session`, and `gdm-x-session` are all listed as "user_interactive", when really they aught to be "background" (_maybe_ one of them qualifies for "utility"). Most of the daemons lpmd tries to list as background are already in systemd's background.slice and are already treated specially by systemd for system resource limits (and LPMD moving them out of that cgroup heirarchy ironically enough disrupts systemd's ability to do that).

Ultimately, this feature is ill-conceived, and I would highly suggest that it be replaced with something that has design involvement from upstream Linux desktops. At the moment, this code being in intel-lpmd excludes it from use, which is unfortunate because we _would_ ultimately like to integrate the OS with the hardware's P/E/L core to extend the battery life for our end-users

Start by reading the code that matches literal process names, the config entries for services such as gdm-session-worker and pipewire, and the logic that moves processes into bespoke .scope units. Check how those paths interact with systemd cgroup hierarchies, resource limits, and OOM handling. Done requires an agreed replacement design that preserves systemd management and addresses the reported security and classification concerns.

Written by the indexing model from the issue text.