Guard transactional file modifications against concurrent modifications

When updating files in a transaction, then we want to make sure that there are no two concurrent callers which can somehow interleave voting on and writing to the file, lest the end result is unclear. Doing this correctly is tricky though: while we could simply take a lockfile during the whole operation and then modify the file in-place, it's possible that the critical section takes a long time and meanwhile blocks all other writers. Alternatively, concurrent readers may see in-between state when the file is being updated in place.

This MR introduces a new locking file writer which allows us to fix this problem and converts SetFullPath and ApplyGitattributes to use it such that we can update those files in a race-free manner. This is a first step towards implementing voting logic which cleanly separates between preparatory and committing votes and thus part of #3709 (closed).