Add test reproducing vim backupcopy=no and kqueue failure

[clintharrison]

This test reproduces the write behavior of vim with backupcopy set to both yes and no. yes is the default on Linux, and #10 fixed this case. Unforunately, on macOS, yes is not the default, and using no will cause ibazel to stop watching the file after a single file save when a kqueue-based file watcher is used. This is described in further detail in #117.

The fix for this might actually be the approach first used in #10 except for the Rename event, not just Remove (that is, waiting for vim to finish writing to the new file and re-adding the watcher on the original filename).

Otherwise, we may need to switch to an FSEvents-based implementation on macOS, which would require some upstream work on https://github.com/fsnotify/fsevents or waiting for fsnotify/fsnotify#11 to be finished.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

[achew22]

The fix for this might actually be the approach first used in #10 except for the Rename event, not just Remove (that is, waiting for vim to finish writing to the new file and re-adding the watcher on the original filename).

Yep, I agree that adding a watcher on Rename is a reasonable way to deal with this. Implementing a new mode for fsnotify is beyond what I'm willing to do.

Thanks so much for sending this PR in. This should hopefully help with one of our longest standing issues. Big big props, I really can't thank you enough! 🎉

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

[achew22]

Marking as manual CLA override because I pushed an extra commit on top of @clintharrison's. When I merge these I will squash and they will become one commit with @clintharrison as the author.