Exponential backoff for retrying renewals

[jcgruenhage]

Splitting this out of #71.

Let's Encrypt recommends that renewal failures should not be treated as fatal errors, but that those should be gracefully retried with an exponential backoff. acmed is pretty far off here (as far as I can tell, I'm not quite sure actually). As far as I can tell, acmed will check each certificate for whether it needs renewal once per hour (at least that's the default) and not do any sort of exponential backoff. Some specific errors are also treated as recoverable, which are then retried 20 times with 1s delay in between. Whether retrying recoverable errors in such quick succession is in line with what Let's Encrypt wants aside, the more important thing would be to implement some for of exponential backoff. Their suggested schedule is retrying after 1 minute, then 10 minutes, then 100 minutes and each subsequent retry after 1 day. I think it'd be in the spirit of acmed to have this as something that's configurable per endpoint, with defaulting to the schedule suggested by Let's Encrypt.

This again is something that's tricky to implement with the current architecture, but should become fairly trivial with the async rewrite.