Avoid file locks by being smarter about when we try to rebuild our information

[anaisbetts]

On Windows, file locks are enforced, meaning that if we try to access files right after they have been written to, it is highly likely that we'll run into locking issues - either by our own app, Antivirus, or by the application that caused the change (many IDEs and editors are also doing similar operations because they also support Git)

Furthermore even on platforms that we don't have to worry about locking, being aggressive about responding to file change notifications means that we will end up looking at a bunch of files that are changing in-progress, especially with projects that do large changes all at once (i.e. Gradle sync in Android projects)

The Plan - scan when we need it, and when we're idle

We actually only really need this information when the user comes back to use GitButler, but since our crystal ball is in the shop, we'll still have to do this in the background to some degree. So instead, we are going to set a really large debounce time (several minutes), but manually signal to debouncer to flush its current notification queue at certain times.

We can eventually try more clever strategies like flushing the debouncer queue once the rate of incoming events slows down, but this is a good first start

TODO:

• [x] Write a version of notify-debouncer-full that allows us to hint when we should flush changes
• [ ] Plumb this through gitbutler-watcher
• [ ] Flush on window focus
• [ ] Flush on system idle

Discussion at https://discord.com/channels/1060193121130000425/1204524097241878629/1237028051800297543