Add notes about care and feeding of unison during filesystem operations

[grayside]

In light of phase2/rig#147, we should consider some documentation updates to set some expectations about unison.

I was thinking something like the following added to the end of ./docs/project-setup/filesystem-sync.md:

## Pushing Filesystem Sync Limits

In practice, it is possible to push the filesystem sync so hard that the process
crashes. The Outrigger team is currently working on improvements to detect and
automatically address this problem.

Unison works well to detect filesystem changes and transfer the files involved
in those changes, but anything which causes a significant amount of change will
first create a significant work backlog, and anything which causes
conflicting filesystem changes that also create a deep backlog can overwhelm the
process.

The following kinds of activities can be expected to be problematic:

* Switching branches in version control where many files are added, removed, or changed.
* Renaming or removing a directory with many files or large files.
* Copying or moving large numbers of files from outside the filesync directory
  into that directory.

If you have found an operation along these lines causes problems, run `rig project sync:stop` first,
run your operation, then restart the filesync with `rig project sync`.

This will allow unison to review the current state of all files as they currently
exist without the potential problems from a flood of filesystem events.

Should we add interim documentation along these lines?

[tekante]

In general I like the information but I think it's missing some context of how to detect a likely failure, the two types of failures that can occur (local machine or container) and how to recover from each. Take @mike-potter's example from today where it was a change inside the container that couldn't sync out as opposed to git operations which are most likely to result in can't sync changes from outside in.

We have a note about problems during sync startup at the end of http://docs.outrigger.sh/faq/troubleshooting/ so perhaps we add a section there about detecting and resolving crashes and point to it from this info?

I think the basics of what ps aux | grep unison and docker ps | grep projectname-sync should return and what to do if you don't see an entry would combine well with what you have here. f you want to start a branch with your proposed changes I can add a section in for proposed troubleshooting and resolution steps.