enhance signal handlers to allow one signalfd per resource along with multiple handlers

[trgill]

cut/paste from discussion in #61

@prajnoha wrote:

if we wanted one signalfd per resource AND we want to support more than one sid_resource_create_signal_event_source call per resource with possible different handler and data passed in, then this comes short - we'd call the sd_event_add_io with _create_event_source only once and not more. So this needs some refinement on how to deal with this (...but systemd itself deals with it because it already uses only one signalfd even though we may call sd_event_add_signal several times). So we should probably do something similar to what systemd does (I haven't looked yet).

...

Just peeked at systemd code: https://github.com/systemd/systemd/blob/79dbbb261d245b619a4d82c1cdf96f6a4310ee0d/src/libsystemd/sd-event/sd-event.c#L1345-L1354

So, yes, they're simply storing an array indexed by signal number. Then each item in the array can hold the callback + userdata (handler + data in SID terms). This way, they can add and remove signal handlers on demand while still using the same and single signalfd (signalfd can be still altered after creating - just passing a new signal mask each time we alter - when we call signalfd with the first arg being '-1', we create the FD with the signal mask... then if we pass that FD to any subsequent signalfd call, we alter the mask).

We might as well do the same signal array in SID - that way we could add/remove the signal handlers for each signal on demand throughout resource existence. Or we can remove it completely by simply closing the signalfd FD. I think we'd need a new extra API call then for "close signalfd completely", not just each signal registration one by one...