Caution: Old peerswap CLN plugin processes don't always die

```
$ ps aux |grep peerswap
cln 729129 0.0 0.0 1173572 868 ? Sl Mar17 0:03 /home/cln/src/peerswap/peerswap
cln 729164 0.0 0.0 1173572 1568 ? Sl Mar17 0:03 /home/cln/src/peerswap/peerswap
cln 1261763 0.0 0.0 1173888 308 ? Sl Apr10 0:02 /home/cln/src/peerswap/peerswap
cln 1261796 0.0 0.0 1247108 824 ? Sl Apr10 0:02 /home/cln/src/peerswap/peerswap
cln 2233765 0.4 0.1 1401056 27684 ? Sl May23 20:01 /home/cln/src/peerswap/peerswap
cln 2723044 0.0 0.0 1247112 268 ? Sl 2022 0:07 /home/cln/src/peerswap/peerswap-plugin
```

The above example is a server that hadn't rebooted in 1 year. CLN was upgraded a few times since then. `lightningd` the parent process launches `peerswap` (or older name `peerswap-plugin`). The child process is supposed to die when the parent dies but in many cases it didn't.

Maybe this isn't a big deal except the older peerswap processes might still have open file handles to the database and unexpected behavior could ensue? Or maybe not since their stdio with their long-dead parent process is gone maybe they're deadlocked. Since those older peerswap binaries are gone I'm unable to gdb backtrace to see where they are stuck. In any case zombie plugins are unable to log via stdio.

Is there a golang signal handler that can act in the event the parent process dies? Would it be safer to use such a thing to ensure it actually does die?