Make sure "bucardo help" doesn't try to connect to a database. Per github issue #64
Remove comment line about spacing - no longer applies.
Fix `reload config` timeout.

First, allow `reload config 30` to work. Resolves #66.

Second, actually *capture* the timeout and wait that long, instead of just
five seconds every time.
Make kick triggers consistently use the non-payload version.
May want to have MCP be able to recognize both versions for backwards compat.
Add daemon role to application name.
Remove listen_payload in unlisten_all().
Check for empty state, too.
Revert "Make kick triggers consistently use the non-payload version."

This reverts commit 25973f4b5ba797568467632b79e8129ffe007f49. I'm pretty sure
this was not the problem, since I have syncs that *do* work with this
approach.

The problem I'm having with a NOTIFY being ignored is that the database in
question is used in two db groups, once as a source, another as a target. As
it validates, it finds the target record before the source, and stores that
one away. Then the autokick is ignored, because Bucardo thinks the DB is a
target, not a source. Working on a fix for that now.
Listen for autokicks on sources for the sync, not all sources.

I had a database in two dbgroups (and syncs), once as a target and once as a
source. On startup, `validate_sync()` was processing the sync where it was a
target, first, and that was the role saved for it in `$self->{sdb}`. Then,
when `validate_sync()` iterated over `$self->{sdb}`, it thought it was a role,
and so did not have the MCP listen for kicks.

Not only that, but sources from other, previously-validated syncs were
unnecessarily listening for kicks!

So change the code to iterate over the list of DBs for the current call to
`validate_sync()`, not all dbs for all syncs, when figuring out whereq to listen
to for kicks.

Note that the use of the same db object in multiple db groups and syncs *may*
cause issues in other places. It would be smart to audit all code that checks
the value in `{role}` for each hash in `$self->{sdb}` and figure out if it is
appropriate. Since the same db can have different roles in differnt syncs, it
might make sense to record all of its roles and to check all of them, rather
than just rely on the first role found.
End syncs on deadlock and serialization failure.

When I added the serialization failure-handling code, I neglected to notice
that it left orphaned `syncrun` rows with no `ended` value. This confused
later syncruns -- like the one that would run after the 0.5s sleep after a
serialization failure. The code was rolling back the main (Bucardo) database
connection, but the syncrun was already committed elsewhere (so that other
processes could see that a sync is in progress, of course; duh!).

So modify the code to instead call `end_syncrun()` and declare the sync
failed, but, of course, with a status recording the seriazliation failure or
deadlock.
Note state value for currently-running sync.
State can also be "Unknown".

Though I am not sure how it gets in that state...
In `status`, if last run is "empty", call it "good".

Two reasons for this:

* An empty run is not a failure, but "Empty" is kind of distracting
  in the output.
* It is useful, if you just kicked a sync, to see that it ran in the output of
  `status`, even if it was empty.
Switch time zone to GMT, as we did in Bucardo4
Don't show serialize/deadlock errors unless we are LOG_VERBOSE, per mailing list discussion.