Flush queue on SIGTERM

Introduces 'gracefulfade' status, distinct from 'fade' in that it
will flush the pending syncs queue. This makes for a shutdown
without dataloss -- no new events are accepted, but those already
in the queue are serviced.

We apply gracefulfade when we receive SIGTERM. SIGINT still uses
'fade' and will only wait for already running processes to exit.

Notes:

 - lsyncdStatus becomes a global and is initialized earlier

 - part of runner.cycle() gets split into runner._cycle_syncs()

 - user alarms are not invoked during gracefulfade (should they?)

 - Sync get a new public method countDelays()
tests: add test for flush queue on sigterm

Note: this test is written in bash.
Consolidate signal handling

consolidates signal handling for TERM, INT and HUP,
while keeping the very few but important differences
in their handling.

This shrinks/simplifies code, and makes those important
differences more visible.

Note: it changes the type and meaning of the 'term' variable,
so changes internal ABI.
Discard events when in gracefulfade (?)

Included here for discussion. I have two theories

 - My testing has failed to win this race cond, but
   this patch is needed.

 - We lose or drop the inotify watches when we receive
   SIGTERM, so this patch is not needed.

   I cannot spot where/how we lose our watches in lsyncd
   code, so this may be specific to linux/inotify, and
   perhaps the fsevents part of the patch is needed.