Use a hash to calculate initial splay

Calculates an MD5 hash of client_name:check_name and uses this value to
determine when to perform an initial standalone check after a sensu start.

Note that there is still a chance to miss a check, for two reasons.  I'm not saying either of these are a problem, but I'd like to make sure you're aware.

First, PeriodicTimer gradually 'slips', causing checks to be executed at intervals slightly longer than the configured check interval. [This gist](https://gist.github.com/hashbrowncipher/f32e2ea081b4c7bd4f8e) containing check execution times from sensu-client.log illustrates this.  The check in question has a 60 second interval.  Upon restart of the sensu client, the MD5 hash of this particular check name will cause it to be executed at 16.595 seconds past the minute.  By the end of the log, PeriodicTimer is executing the check in question at 17.728 seconds past the minute.  So any Sensu restarts between 16.595 and 17.728 seconds past the minute will cause the check to be dropped.  By linear extrapolation, in 23.64 days PeriodicTimer will be scheduling the check at 46.595 seconds past the minute.  As a result, any restarts between 16.595 and 46.595 seconds past the minute (a 30 second interval) will cause a check to be lost.  The window for lost checks will gradually widen to the full 60 second check interval, at which point it will wrap around back to zero.  This issue could be fixed by essentially performing calculate_initial_splay at schedule-time for each check, rather than relying on PeriodicTimer.

The second way that checks can be lost is in the interval during a Sensu client restart.  The restart isn't instantanous, and checks will be lost during that period.  I'm pretty certain this problem isn't worth fixing.

I have tested this change with standalone checks on one of our servers.  It performs as expected, rescheduling checks at exactly the same time across restarts. 

Fixes #795.