API improvements around Executor/Executable

Additional change suggestions on top of PR 1610

IIUC, the expectation here is that Queue.Executable will instantiate AsynchronousException as a handle, start something asynchronously (say send a JMS message) with a callback, and the callback will tickle AsynchronousException.

So AsynchronousException might complete before it gets its executor set. This code change ensures that that case gets handled correctly.

Update the retention strategies... the JSR 305 annotations do not seem to be spec'd to apply to child methods also... bold poorly spec'd annotations

Remove `jenkins.setNodes(jenkins.getNodes())` style hacks to force the master number of executors to be updated

- We will never mind that this is probably the wrong import to use as Jenkins core is consistently using the
  wrong one (If anyone asks, for a `javax` import to be correct, it should have a JSR that has passed through voting
  and not have a JSR that is still subject to change... OTOH one could argue that if the JSR 305 should ever
  become revived from its current dormant state *and* it is decided to include in the JRE *then* the packages
  would get moved out of `javax` and into `java` so they are not in final form anyway... but that pre-supposes
  that the process of standardization does not modify the annotations and by virtue of being in `javax`
  there will be some special case handling by some classloaders which is why depending on the JSR305 versions
  is, in my view, a bad plan... anyway this is moot... Jenkins core is going with JSR305 as it currently stands
  so we call all go down together!)

Clarify the cases where we hand-roll in the optimized subset of a save() and how config files are maintained

(yes `} finally { updateSnapshot(); } } finally {` looks ugly but it reduces the amount of indentation changes)

Ooops, forgot that the setting of nodes needs to happen while the Queue lock is held and the computer list needs updating afterwards