Don’t let job start time drift later and later

Because jobs were supposed to wait at least their period length before running again, their actual start time would slip further and further from their expected start time. (With the default sleep_timeout of 1 second, we observed a drift of about 0.6 seconds per period. On average, each hourly job ran 1 hour + 0.6 seconds later than the last.)

For an hourly job, if the last job ran at 10:00:00.5 it should be safe to run again at 11:00:00.1. By pretending the last job actually ran at the beginning of the second (10:00:00.0) we are able to trigger the new job on time.
Default sleep_timeout to 0.5 seconds to not skip any seconds

Because sleep means “sleep at least this amount”, and because there is some processing between sleep calls (even though it’s trivial), with a sleep_timeout of 1 second it is possible for the manager to pass over a second without ticking. (E.g. tick at 10:00:00.999 and tick at 10:00:02.001, but nothing during 10:00:01).

The previous commit ensures that Clockwork won’t let job start times drift later and later *as long as* the manager ticks once during every second.

Changing the sleep_timeout to 0.5 seconds make sure the manager ticks at least once during every second.

With this change and the previous commit, Clockwork *by default* will not allow jobs to start running later and later.
Revert "Default sleep_timeout to 0.5 seconds to not skip any seconds"

This reverts commit 7f0aed8d2889fd16dacb3143b73e436bd364e99e.
Wait until the next second
Warn if sleep_timeout < 1
Merge branch 'dont_let_start_time_drift'
Version 1.1.0

Accept #135 to fix drifting start time.
As a side effect, sleep_timeout < 1 is disallowed.