Fix ETXTBSY for Coursier fetch.

[jsirois]

Some of our Processes use system binaries to run scripts in the input
digest of the Process. This foiled the original ETXTBSY fix which was
only used when argv0 was a member of the input digest. Coursier fetch
was an example of this, using the system provided bash to execute a
script in the input digest which in turn executed a binary in the input
digest.

Fix this by just pessimistically assuming all Process invocations will
execute files in the input digest and always performing the mitigation.

Fixes #13424

[ci skip-build-wheels]

[tdyas]

thanks!

[jsirois]

Hrm, I just realized it won't help the case in #13424 since there the process tree is:

/usr/bin/bash ./coursier_wrapper_script.sh
  -> ./cs-x86_64-pc-linux

In other words; although this fix mitigates the top level process encountering ETXTBSY, it does nothing for the child ./cs-x86_64-pc-linux process spawn since that spawn is fully controlled by bash and runs concurrent-to-or-after our process spawn of /usr/bin/bash ./coursier_wrapper_script.sh returns control to us and we exit our lock. In #13424 it was exactly that child process spawn from within bash that had the issue.

[jsirois]

It's worse - even that 1st invocation isn't helped here because it has 0 problems: bash exists on the system and that is the only binary in that invokation - it will never trigger ETXTBSY. It spawns and then reads in ./coursier_wrapper_script.sh on its own using libc which doesn't care who else may have the file open.

Updated the issue with this more thought out scenario and suggested a bad idea. I'm going to close this PR and hope people pile on to that issue with better ideas.