SIGTERM handling & SIGKILL cleanup

[jean-emmanuel]

Following up on #205, I finally managed to understand what was causing some parameters to not update as expected. It appears that when the process receives a SIGTERM or SIGKILL signal, on next start it will be in a state that doesn't work as expected (the first value submitted for a parameter will be stored in cache but not pushed to the hardware, and only a value that differs from the one in cache will be pushed to the hardware afterwards). From what I could test, a "bad start" is always characterized by a number of parameters raising errors when attempting to unlock them, adding a log here in case of error response shows that it occurs systematically when restarting after a SIGTERM or SIGKILL, I don't know if it's the cause or only a symptom of the issue, but I've never seen a single unlock error after a graceful termination of the process (SIGINT) so it's definitely a relevant clue.
Handling SIGTERM would be simple enough, handling it as SIGINT currently is (https://github.com/alsa-project/snd-firewire-ctl-services/blob/master/runtime/fireface/src/latter_runtime.rs#L198) works fine, but SIGKILL (and presumably SIGSEGV if it were to happen) requires a better understanding of the application than I can provide: I can only guess one could do some checks / preventive cleanup on startup to prevent the issue if some resources were not released correctly. What do you think ?

PS: I'm only using snd-fireface-ctl-service with a FF802