We sould factor catching of IO exceptions into applyToWorking to 
reduce duplication, now that we do it uniformly whenever we call it.

We also sometimes call applyToWorking inside withSignalsBlocked but 
not uniformly. We do it for clone (when conflicts are marked), 
unrevert, mark-conflicts, and for pull and apply via 
standardApplyPatches. But not for rollback, revert, unrecord, 
replace, rebase suspend/unsuspend.

I fail to see the pattern here.

The apparent rationale for withSignalsBlocked is that an interrupt 
(user hitting Ctrl-C) would mean that changes may be applied 
partially, leaving the working tree in an inconsistent state. Makes 
sense but again I can't see a reason not to do this uniformly, which 
means we can also factor it into applyToWorking.

The following patch sent by Ben Franksen <ben.franksen@online.de> updated issue issue2626 with
status=resolved;resolvedin=2.15.0 HEAD

* resolve issue2626: treat applyToWorking more uniformly 
Ignore-this: a4a3d604838c74302395a77c6e08a66a0d0383d78fac44db36af32be72deb5129ef026cece930b47

This factors catching IO errors into applyToWorking with a generic error
message that should fit all use cases. In case of the 'convert darcs-2'
command, the extra clarification that suggests to use --no-workingdir has
been removed as I find it misleading and cannot see how that could actually
help: we have created the whole working tree ourselves, so if applying the
patches fails something really weird (like another process interfering with
the working tree) must be going on.

It also adds a number of withSignalsBlocked to wrap the calls to
applyToWorking where they were missing. Where possible, the scope of actions
under withSignalsBlocked is extended to include finalization and/or updating
the pending patch. This has previously been the case for some commands but
not all of them.