watchman: use launchd to spawn service

Summary:
we've seen a couple of cases where our mach connection to the
FSEvents service winds up in a broken state.  The theory is that this
is somehow related to the user logging out or from different security
contexts.

This diff hopes to avoid the issue by tying the user watchman process
to the GUI session of the user.

How it works: instead of daemonizing when we fail to connect to the
server socket, we construct a plist containing the invocation options
and place it in the user LaunchAgents directory, then request that
launchd load that plist.

We're asking launchd to manage the listening socket for us to handle
the case where the user issues a `watchman shutdown-server` command.
We do it this way because the process termination leaves the service
in a "waiting" state from the perspective of launchd; when in this
state, an attempt to load the plist again fails with an EAGAIN status.
By having launchd listen on the unix socket for us, it knows when to
trigger the watchman process and pass the descriptor over to it.

Once watchman has been successfully spawned via launchd for a user,
subsequent logins will load the plist at login time and cause launchd
to listen on the watchman unix socket, spawning watchman on demand.

If the user only ever logs in to their system using the GUI, what winds
up happening is that watchman will get shutdown when they log out of
the GUI and respawned on their next watchman query/request in their
next GUI login.

If the user logs in without a GUI running (eg: via ssh) and spawns
watchman, it will fall back to old fashioned daemonize to run the
server.  It will remain running even after the ssh session terminates.

If the user subsequently logs back in on the GUI, launchd will replace
the unix socket with its own, effectively orphaning the non-GUI server.
It would be great to have a way to detect when this happens.  Aside from
stranding the process, it doesn't harm the user experience with
watchman; they'll have a launchd spawned process that operates correctly
and that will get shut down when they log out.

Test Plan:
`make integration` still passes (it uses --foreground explicitly anyway).

In a GUI session:

`./watchman watch-list` writes out the plist and registers it with launchd.
`launchctl list | grep watchman` shows that it is registered
`ps -ef | grep watchman` shows a running watchman process with the
log, socket and state paths set explicitly (per the plist file)

Logging out of the GUI, logging in via SSH:

`pgrep watchman` shows no processes (it got shutdown on logout)

Logging back in to GUI:

`launchctl list | grep watchman` shows that it is registered
`pgrep watchman` shows no processes (nothing has triggered it to spawn yet)
`./watchman watch-list` spawns watchman and returns the watch list
`./watchman get-pid` and note it

Logging in via SSH while GUI is running:

`./watchman get-pid` shows the same pid as above; watchman continues to respond
as per normal.

Logging out of the GUI, then in the SSH session:

`pgrep watchman` shows no processes
`./watchman watch-list` tries to spawn watchman via launchd, reports an error (on stderr)
and falls back to daemonize, then responds with the watch list from its non-launchd invocation.

`ps -ef | grep watchman` shows a `watchman watch-list` with `init` as the parent.

Logging back in on a GUI:

`ps -ef | grep watchman` shows the `watchman watch-list` with `init` as the parent.
`./watchman watch-list` spawns a new watchman server via launchd, responds with expected results.
`ps -ef | grep watchman` shows both the launchd spawned instance and the init-parented server.

Logging out of the GUI, then in the SSH session:

`ps -ef | grep watchman` shows only the init-parented server
`./watchman watch-list` spawns a new init-parented server (because launchd orphaned the original unix socket)
`ps -ef | grep watchman` shows two init-parented servers

Reviewers: sid0

Reviewed By: sid0

Differential Revision: https://reviews.facebook.net/D28161