Diffa Diffa

(This ticket probably depends on #294)

#272 introduced a simple first working version of the escalation facility that allows scan to trigger a set of entity scoped actions.
This trigger fires whenever a scan is run for every entity scoped
action that is configured to escalate. The primary use case of this is
to be able to configure a scheduled scan (e.g. to run once overnight)
that will invoke a pre-defined repair action.

The scope of #272 is deliberately limited, hence this ticket addresses
the areas where the escalation manager should be made more flexible
and powerful. Here is a list of features it should have:

• The process of escalation should be polling driven, not event driven
• A series of ordered escalation steps should be configurable
• Each escalation step includes an action that could invoked. The escalation could be an repair action or a notification. Potentially
  the URL field could be misused to define an SMTP recipient.
  
• The state of an escalation is held persistently until a match event for the underlying entity occurs. The final possible state of an
  escalation will be the result of the last configured action. After
  this step has been invoked, only a manual intervention can repair the
  underlying entity.
  
• It should be possible to review all current escalations.
• The configuration XML needs some thought, because it is likely that escalations will re-use repair definitions, so we will need to come up
  with concise way of defining the config.