RFR: 1827: Better handling of Error

[Erik Joelsson]

After some deliberation, I think this is how we should handle an `Error` being thrown when running a `WorkItem`. 

We need to attempt to log it and register it in the counters, otherwise it will be very hard to discover the problem. 

We also need to attempt to return the scratch path to the BotRunner, as well as removing the item from the active set, otherwise the BotRunner will enter a broken state. The drawback of this is that it will allow new instances of the same WorkItem to run, which will likely repeat the Error. I still think that's the better option compared to what we experienced in SKARA-1825.

I think it's fine to skip scheduling of pending items. When an Error has been thrown in a thread, we should try to minimize any additional work in that thread to only what's necessary. Unless every WorkItem throws an Error, pending items will get scheduled eventually anyway, by some other successful WorkItem. If every WorkItem is throwing an Error, then not scheduling pending items is the least of our problems. By re-throwing the `Error` we make sure the Runnable exists as quickly as possible.

-------------

Commit messages:
 - SKARA-1827

Changes: https://git.openjdk.org/skara/pull/1490/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1490&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1827
  Stats: 11 lines in 1 file changed: 8 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1490.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1490/head:pull/1490

PR: https://git.openjdk.org/skara/pull/1490