Failure automation improvements

[smartin015]

Currently, "spaghetti detective" integration merely looks for print cancellation and retries the print if the event happens early enough in the printing process (so as not to waste time restarting longer prints).

• Use "initiator" events
  Recent improvements to TSD add the concept of a command initiator, which we can use to differentiate "spaghetti detected" from "user clicked a button". Automation should get out of the way in the latter case. This requires some small code tweaks in the plugin.
• Configurable detection
  There are some prints we may not want TSD to monitor - specifically print queue clearing and queue finishing. It would be neat to have a way to disable TSD specifically for those prints, so as not to interrupt the queue process with false positives.
• Generic event processing
  Other failure modes may emerge (e.g. this FR) which may require different actions depending on current state. The current code isn't well set up for such additional events and will likely need a refactor. Failure recovery logic will likely become increasingly complex as development on Distributed Multi-Printer Support #35 and other features continues. It may be worth refactoring to set up a list of configurable actions for specific failure events, in an IFTTT style.
• Advanced diagnosis
  We can potentially perform an automated "test print" if a single print has failed many times, to diagnose whether the failure lies with the print (e.g. bad orientation) or the printer (e.g. bed isn't sticky enough). This would allow bad prints to be set aside and the printer to continue without needing a human to decide whether to keep printing.
• Historical tracking
  When we have the ability to diagnose failures, we can then track causes over time, compute probabilities, and use that to refine estimates of how long a particular print job will take.

[smartin015]

I split the remaining features into #216 and #217.