"Graceful runtime" for managing job runtime when lumi splitting

DMWM would like to experiment with managing maximum job runtime by using the concept of "graceful runtime" introduced in this patch.

The basic idea is that, after a fixed amount of runtime, the InputSource will stop on lumi/run/file transitions.  The workflow management system will do accounting for the processed lumis and be able to create a new job from the unprocessed lumis.  This makes the lumi section the unit of work, not the job.

Why is this interesting?  This will get us a step forward toward deterministic job runtimes without breaking the atomicity of the lumi.  This should help with processing tails (no very long jobs) and overall efficiency (less likely a user will submit a task consisting of 72 hour jobs, all of which are killed at 48 hours).

To be clear - this is an experimental idea and may be several months before the DMWM team can tackle it.  However, in order to try the idea we need the framework support found in this commit; it should have negligible runtime impact unless actually in use (and, when in use, should cost about 30-40ns per event).
Why should this be called often? Isn't this only called on lumi boundaries or at most every event?
The class you want is either ```std::chrono::system_clock``` or ```std::chrono::steady_clock```.