Withdraw a raised delete once its file is in use again

[SimonCropp]

A delete is raised for a verified file no target produced, and waits in the tray or the viewer for someone to accept it. Nothing withdrew it when the file came back into use - a target that came back, or a snapshot that moved inline and then back out when the global switch was turned off - so accepting it removed a file a passing test depends on, and the next run failed for a snapshot that had been fine.

A verification now withdraws, through DiffRunner.SettleDelete, the pending delete of every verified file it compared against, whether the comparison matched or not: a file that no longer matches is still the target of a pending move.

Withdrawing for every verified file would cost a round trip to the queue owner per file, for every codebase. So the run that raises a delete records the file under the intermediate directory, before raising it, and only a recorded file is withdrawn. With nothing recorded that costs one directory check per process. A record whose file has gone is dropped when the records are read: accepting the delete removed it, and a tray drops a delete whose file is missing.

Both answer to DiffRunner.Disabled, as raising always has, and a run that cannot reach the owner leaves the records for one that can.

Per configuration and target framework, like the received maps: a delete one framework's run raised is withdrawn by that framework's next run that uses the file.

SettleDelete arrived in DiffEngine 20.5.0, which is already referenced here.

Tests

RaisedDeleteTests covers a delete withdrawn once its file matches again, and once it no longer matches; records left for a later run where DiffEngine is off; nothing recorded while it is off; a record whose file has gone; and nothing sent when nothing was raised. Each was checked against the unfixed code.