Make "watch = false" the default

The "watch" preference defaulting to "true" has caused some issues
([1] [2] and some others) to users who may not even know they are
running with the watcher enabled. With some of these bugs unresolved
and watcher semantics still somewhat confusing and limited (see
below), I'd like to initiate a discussion to make "watch" preference
default to "false". This default can then be revised again once
critical bugs are fixed and semantics extended or better documented.

The exact proposal is this:
1. "watch = false" becomes the default for everyone.
2. "watch" is automatically flipped to "true" if "-repeat watch" is specified.

Reasoning for point 2 is simple: "-repeat watch" requires "watch =
true" and specifying "repeat" is the only request the user should make
or be forced to know about.

Reasoning for point 1 can now completely exclude scenarios where the
user has specified "-repeat watch". It is my assumption that using
"watch = true" without "-repeat watch" is currently almost always a
result of the defaults, not of user intention. There is no clear
documentation of the "watch" preference for users to base their
intentions on.

I have investigated the code a bit and my current (possibly limited or
incorrect) understanding is that a) the "watch" preference without
"-repeat watch" is only leveraged by the GUIs; and b) the effect of
the "watch = true" without "-repeat watch" is limited to non-existent.
Users (in general, but even more so when using the text UI) are not
getting any benefits from the default preference, yet they are exposed
to potential bugs.

The limited to non-existent effect claim is based on my understanding
that input from the fsmonitor process is used solely to filter the
(static) list of paths Unison is going to scan. The list of paths to
scan itself does not come from fsmonitor process, it is the list of
paths from the profile. For example, if the user has not specified any
explicit paths then the paths to scan are the roots. Here, the effect
from "watch = true" is binary, either not scan the root (no changes
reported by fsmonitor) or scan the entire root (any change reported by
fsmonitor). This may sound like somewhat of a benefit but it has to be
put in context: first, it currently works only in GUIs (for example by
clicking the "Rescan" button; but not when specifying "-repeat N" on
command line), and second, re-scanning even big roots tends to be very
(even extremely) fast (assuming much has been cached). It may be
slower on Windows (I have no empirical data) but again, the decision
not to scan is made only if fsmonitor has not reported any changes at
all.

Please do correct me if my understanding is incorrect at any point.

At the moment, the fsmonitor binary is not packaged on Windows due to [2].

[1] https://github.com/bcpierce00/unison/issues/329#issuecomment-708633505
[2] https://github.com/bcpierce00/unison/pull/493#issuecomment-823419018