Create an PeriodicClosure class.

Some improvements over the existing class, but at the same time, some of its issues (at destruction time) have not been fixed, only better documented.

One important thing you usually want to know when destroying this object is whether the closure will be called again. To support destruction from arbitrary threads, it would be easy to make the destructor block until the closure returns, but it would still not allow destroying the object from within the closure.

Since supporting destruction from arbitrary threads would be kind of complicated, and I'm not sure if @AlCutter even needs it, I figured I'd [YAGNI](http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) it. I have a much better idea that will support stopping it from other threads **and** from the closure, but it requires some more support code, so I figured I'd put this out first, since it was easy (and might be enough to unblock @AlCutter!).
Another thing that's "peculiar": this API really only works "properly" if what you're doing in the closure is synchronous, otherwise, you might get called again while your first operation (whatever it is) hasn't completed yet. And if you're doing network I/O synchronously within a libevent callback, you're going to have a Bad Time (tm). :wink:

Even in the case of a slow down, if you *just* refreshed the master proposal (and it took a bit of time), would you really want to refresh it *immediately*? If adding up to a period to this would make you lose mastership, you probably have other problems, and maybe you should step away from it. :smiley: 

This is something I think a watchdog might help (and by "help", I mean "kill you dead", so you'd definitely lose mastership).