Refactor spec/mgr to move monitoring/sleeping to spec

[ferringb]

In the process, this adds support for Begin and Interval to spec's. It also restructures the flow to make it so that new spec options- splay for example- can be added at the spec level and/or inherited from the manager level. That's the intended end goal.

To get there, the 'control' had to be flipped from the manager (which should just be a dumb collector/holder of specs) to the specs for execution- this was accomplished via integrating context usage in. In doing so, proper reload support was added and opportunistic reload was removed- certmgr no longer tries to reload spec's unless it's explicitly told to do so. The upshot of this however is that certmgr now no longer requires a restart to reload all spec's- it's now able to do so.

That's a brief summary; see the commit messages for full details of each.

This PR primarily just restructures things for feature additions that will follow, while also realigning encapsulation so I can bury more internal details. Followup work will be thus:

• Addition of splay logic; that'll be simple enough.
• Optional rewrite mgr's parsing logic of /etc/certmgr/certmgr.yaml to actually use yaml instead of viper's internals; in the process, this will add actual errors if configurables are specified and unknown.
• Optional control socket. This is primarily useful for salt interactions and for proper reload invocations by systemctl (the certmgr reload could return nonzero exit if the running instance detected config issues for reload).
• Mostly non-optional: refactor spec api enough that arbitrary client libraries can pass a notification callback in for when content changes. The main pathways should be refactored to use the same- in doing so, this will also allow for defering the 'store' step to the invoker (for example, to put the keys/certs in an environment of a process).
• Optional and as a follow on- and I strongly mean optional- implementation of certmgr run --spec <spec> binary <args>. If this is an hour to implement, I'll do so, if not, I'll leave it as an exercise for others.

[ferringb]

If folks have a better idea of how to handle unmarshal'able structs and the misalignment of configurables... specifically how to handle that without requiring me to duplicate fields (or define duplicate interfaces to accomplish this)- I'd be interested. I'm not a huge fan of what I had to do here for parsing, but I'm also working around configs I've been forced to inherit rather than what I'd design in a green field situation.