Improve --debug output to show pid of processes that are started and stopped

getPid returns Nothing if the process has already been stopped, and in that
case, the pid will not be displayed. I think that would only happen if
waitForProcess or similar gets called more than once on the same process
handle though.

getPid on unix has an overhead of only a MVar read. On Windows it needs to
make a syscall, so will be probably more expensive. While the added expense
happens even when debug logging is disabled, it should be small enough
compared with the overhead of starting a process that it's not a problem.

(It does occur to me that a debugM that took an IO String could only run it
when debugging is really enabled, which would improve performance. It does
not seem possible to use the current hslogger interface to do that though;
it does not expose the information that would be needed.)

doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages/comment_1_3b069234f20378fc231802c594eb213d._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-24T16:32:14Z"
+ content="""
+I've added the pid.
+
+This happens at a layer that only knows the process exited, not what it was
+used for. Of course if we know the process in question the higher layer
+that uses it could be made to log something more informative, if
+the nonzero exit is really unexpected.
+"""]]