fix: allow calls for systemd graphical target to fail

[jokeyrhyme]

• extracted out common std::process::Command work, and made that function swallow errors rather than return them or panic (because we want to keep systemd optional)
• pass a null stdin to std::process::Command, because it's allegedly faster to skip inheriting the parent's stdin (and it's not our intention to allow this inheritance anyway)
• switch from .spawn() to .status() so that we can at least find out if systemctl accepted our calls (mostly for diagnostic purposes)
• pass --no-block to systemctl when starting/stopping the graphical target, because we care mostly that we called into systemd successfully, not what happens inside systemd after that

in all testing below, the session and compositor continue to launch as normal:

• tested the happy path, and that systemctl --user status cosmic-session.target shows it is active
• tested with systemctl-foo as the hardcoded command, to confirm that that the Err branch results in the expected logs, and that systemctl --user status cosmic-session.target shows it is inactive
• tested with cosmic-session-foo.target as the hardcoded target, to confirm that that the non-zero exit status code branch results in the expected logs, and that systemctl --user status cosmic-session.target shows it is inactive

[jokeyrhyme]

Another thought I had is that we could detect systemd the same way cosmic-comp does (using the libsystemd crate), and then change the behaviour of this PR (or in a follow-up PR) to not even attempt to call systemctl if systemd is not running

That would keep logs cleaner on non-systemd systems

[Drakulix]

Another thought I had is that we could detect systemd the same way cosmic-comp does (using the libsystemd crate), and then change the behaviour of this PR (or in a follow-up PR) to not even attempt to call systemctl if systemd is not running

That would keep logs cleaner on non-systemd systems

It might, but we would pull another dbus api, which we don't really need. It think this is fine.