This changes the startup logic pretty significantly, to provide
comprehensive protection against many clients all attempting to start
the daemon at the same time.

A lockfile is used to ensure that only a single contender is responsible
for either starting the daemon script, or usurping a wedged or
misbehaving server.

The lockfile contains the pid of the server attempting to take over, and
is checked to ensure that it STILL contains the correct pid before
confirming, to handle the race when multiple contenders all try to
delete a stale lockfile at the same time. That is, the lockfile used as
a mutex against startup races is also subject to races, since it can be
disregarded and deleted if it's stale, so that has to be protected
against.

This also makes it so that it attempts to listen *first*, and only
usurps a wedged process if the listen fails, which is more efficient in
the common happy-path case, and only involves minimal waiting in the
edge cases.