Revert "Honor preempt_delay setting on startup."

This reverts commit c7a985db4136b374dbee25caa39aa121bc16fb7d, and
fixes #80.

This commit resulted in two individual bugs:

1) A keepalived instance coming on-line would not transition to MASTER
state until the preempt_delay duration had passed, even though there was
no already existing VRRP speaker in MASTER state on the link. In other
words, it changed the semantics of preempt_delay from a delay that only
took place before *preemption* of another VRRP speaker, to a delay that
unconditionally took place after Keepalived came online. The
keepalived.conf manual page has always documented the former meaning,
which is also IMHO the only one that you would intuitively expect.

2) The preempt_delay was applied when a Keepalived process was reloading
its configuration following the recipt of SIGHUP. If the Keepalived
instance was in MASTER state before the reload, it would cease
transmitting VRRP hellos for the duration of preempt_delay, but *not*
actually remove the virtual addresses from the network interfaces. This
in turn resulted in any backup VRRP speakers on the links transition to
the MASTER state while preempt_delay was still in effect on the original
MASTER that was reloaded, thus creating a service-impacting split-brain
scenario where the virtual addresses are present and active on multiple
VRRP speakers simultaneously.

If the functionality that c7a985d aimed to implement really is needed in
Keepalived, it should instead be implemented using a separate
configuration setting independent from preempt_delay. An appropriate
name for this new setting could be for example "startup_delay" or
"initial_delay". However, it could also be implemented in the init
script, by starting keepalived with e.g. "sleep N && keepalived" where N
would be the desired duration of the initial/startup delay.