notify-send-based senders (e.g. breadcrumbs) fire a new process per
notification, so replaces_id is always 0 — they instead tag related
notifications with the x-canonical-private-synchronous hint and expect
the daemon to replace whatever's currently showing from that app. We
weren't honoring it, so a persistent (Expire::Never) critical
notification like breadcrumbs' "no Wi-Fi adapter" during a suspend
transition could never be superseded by a later notification, leaving
it stuck until breadbar was restarted. Fixes#2.
