Implementation of delay feature to job alerts.

This add an optional delay field to job alerts. Delay is specified in units of minutes. When an alert has a positive integer for a delay:

* If the alert is triggered then it is scheduled for delivery in N minutes from now.
* If the alert is cleared and it has been scheduled for delivery then the scheduled alert is cancelled.
* If the alert has changed description then the previously scheduled alert is cancelled and a new alert is scheduled.

If an alert cannot be scheduled for later delivery or the alert cancellation is unsuccessful then the alert is delivered immediately. When the spawn process is shutting down then any outstanding delayed alerts are delivered immediately. I have tested the delayed submission of an alert on local stack and have tested firing an alert and immediately clearing an alert with no email sent.
that compilation error is from all your other erroneous usages. Java definitely allows sub-classes (and sub-interfaces) to declare signatures with monotonically tighter restrictions on exception declarations. So narrowing to specific exception sub-classes, and banning checked exceptions entirely are both permissible and common.

for instance, see this bit of javadoc from the `AutoCloseable` parent class:

     * <p>While this interface method is declared to throw {@code
     * Exception}, implementers are <em>strongly</em> encouraged to
     * declare concrete implementations of the {@code close} method to
     * throw more specific exceptions, or to throw no exception at all
     * if the close operation cannot fail.

I also typically use `AutoCloseable` over `Closeable` unless I am actually throwing `IOException`s and/ or the idempotent close method contract is extremely important.

ps. I explained this for your future reference, but with the alternate solution I proposed, no resource management is necessary.