add coredumpd support

This only does something when used with a new enough KCrash.

Coredumpd is a coredump handler that comes with systemd. When a process dumps its core it is sent to coredumpd which records the crash in the systemd journal and stores the core on disk. This allows us to pick up the crash after the fact and file a bug report. For example when software crashes on session logout.

To facilitate bug reporting KCrash writes the metadata we ordinarily get through ARGV to disk as an INI file. Since we still want to support both operation modes this commit introduces large amounts of extra tooling specifically meant to connect coredumpd crashes, to metadata, to drkonqi argvs. All of this does depend on systemd and is generally working with version 245, but 248 is vastly more recommended because of various refinements and bugfixes.

Architecturally a coredumpd crash works like this:

KCrash

The app crashes. KCrash's signal handler runs. It records the metadata to a file in ~/.cache. Re-raises the signal to then trigger a core dump.

coredumpd

Coredumpd gets invoked by the kernel, captures the core, records the crash with all the metadata it has available (proc maps, pid, time, etc.) to journald. It does this by invoking an instance of systemd-coredump@.service

drkonqi-coredump-processor@.service

This is wanted by systemd-coredump@.service and instantiated using the same instance "name" as coredump@ (this then allows us to find the correct crash). The processor connects to journald and searches/waits for the crash for the correct coredump@ instance to appear in the journal. Once the crash record has been found a connection to a user-scope socket is opened...

drkonqi-coredump-launcher.socket

Is a user-scope socket that purely exists for drkonqi-coredump-processor@.service to talk to. When a connection is opened an instance of drkonqi-coredump-launcher@.service is spun up to deal with the traffic.

drkonqi-coredump-launcher@.service

Is the actual launcher service, it is socket activated from system-scope. On the socket it gets the crash metadata streamed from the system-level processor (thereby eliminating the need to talk to journald again - the processor forwards the data it looked up).

The launcher then glues the coredumpd metadata into the same file as the KCrash metadata, turning the .ini file into a comprehensive record of the crash.

Once the file is complete it forks drkonqi with the same arguments as though KCrash had invoked it directly so the user can file a crash report.

Drkonqi

Drkonqi itself has grown a new CoredumpBackend analogous to the KCrash backend. Its main concern is preparing the core for tracing. Depending on the systemd version that is either delegated to coredumpctl (the CLI for coredumpd) or partially done on our end. In either event coredumpctl is a runtime requirement to not have to concern ourselves with where a core is actually stored from the coredumpd side of things (could be compressed, on disk, or in journal).

gdbrc now also supports the coredump backend by extending the commandline templates with core-based tracin, for the coredump backend only. As a side effect, debuggers now can have a corefile template variable which is the path to the on-disk corefile in the event that the legacy coredumpd backend is used. Newer coredumpd-248+ allows us to invoke gdb through coredumpctl directly, eliminating the need to faff about with core files manually on our end.

Everything else stays the same. As far as the UI bits are concerned nothing changes between a kcrash backend and a coredump backend.

Metadata file presence currently is doubling as "this crash has not been dealt with" indicator. As such, metadata files are only cleaned up if the user somehow interacts with drkonqi to discard the dialog. This is to assist with future development to implement "an application has crashed in the past" style behavior (e.g. when apps crashed on logout).

drkonqi-coredump-cleanup.{service,timer}

Is a cleanup system in case crashes fall through the cracks and don't get their metadata files clean up. This is largely a stop-gap measure because this commit does not deal with actually picking up crashes that happened at logout - this requires additional UI engineering first.