Delete subprocess output tempfiles once they are read

[ybai08]

Fixes #899

Subprocess.spawn captures the child's stdout and stderr in two Tempfiles and never closes them, so deleting them is left to the garbage collector. On Windows that delete fails with Errno::EACCES when a process left behind by the command (for example the inner ruby.exe of bundle exec rspec) still has the file open, and Ruby prints the finalizer backtrace from the issue on every hook run.

This closes and unlinks both files (Tempfile#close!) in an ensure once the output has been read, so they are gone when spawn returns, including when reading the output raises. As suggested in the issue, this goes through Tempfile#unlink rather than File.unlink, so a delete that Windows refuses is ignored instead of raising.

spawn_detached is unchanged: its child is still running when it returns, so its files are still left to the garbage collector.

Tests

Two examples in spec/overcommit/subprocess_spec.rb record the Tempfiles that spawn creates and check that both are closed and unlinked (Tempfile#path is nil) after it returns: one for a normal run, one where reading the output raises.

The suite was run on macOS with Ruby 4.0.7:

• bundle exec rspec spec/overcommit/subprocess_spec.rb with lib/overcommit/subprocess.rb reverted to master: 10 examples, 2 failures, both on expected ... closed? to be truthy, got false. With the change: 10 examples, 0 failures.
• bundle exec rspec: 1657 examples, 4 failures. The same 4 examples fail on master (1655 examples, 4 failures): the git alias #amendment? examples in hook_context/commit_msg_spec.rb:134,140 and hook_context/pre_commit_spec.rb:43,49, which look specific to this machine's Git (Apple Git 2.54).
• bundle exec rubocop: no offenses.

Not run: anything on Windows, so the Errno::EACCES warning itself was not reproduced; bundle exec overcommit --run.