update README.md with a snazzy gif!

Summary:
Also tweak wording in a couple places, and delete the stub manpage until
we decide to flesh it out.

The gif was generated from my https://github.com/oconnor663/dotfiles
repo using ffmpeg and convert (imagemagick). The relevant commands were:

```
ffmpeg -y -framerate 10 -video_size 602x338 -f x11grab -i :0.0+54,207 \
    -preset ultrafast -qp 0 out.mkv
ffmpeg -i out.mkv frame%04d.png
convert -delay 10 frame*.png -layers OptimizeFrame out.gif
```

- I used `xwininfo` to grab the dimensions info for the first command. I
  also subtracted the width of the scrollbar, measured with a screenshot
  in Gimp.
- The `-y` flag automatically says yes when prompted to overwrite an
  existing video file (this seemingly optional flag actually avoids a
  nasty bug: https://trac.ffmpeg.org/ticket/3989).
- `-qp 0` makes sure the video is recorded losslessly.
- `-preset ultrafast` skips most compression, to take load off the CPU,
  since we're recording in real time.
- `-layers OptimizeFrame` does some very clever gif magic to remove
  duplicate pixels between frames, which shrinks our gif by ~4x.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D102

README.md

@@ -5,9 +5,11 @@
 Peru is a tool for including other people's code in your projects. It's a lot
 like [git submodules](http://git-scm.com/book/en/Git-Tools-Submodules), except
 that peru stays out of the way of your other tools. You write a `peru.yaml`
-file and then run peru when you feel like it, like in your build scripts or in
-your source control hooks. Your projects can live in git, hg, svn, tarballs,
-whatever. And your dependencies can too.
+file and then call `peru sync` when you need code, either by hand or in your
+build scripts. Your projects can live in git, hg, svn, tarballs, whatever. And
+your dependencies can too.
+
+![snazzy gif](https://raw.githubusercontent.com/buildinspace/peru/master/docs/peru.gif)
 
 ## Why?
 
@@ -215,8 +217,9 @@ up to date, and you'll still be able to reach old versions in your history.
   There are also fields you can use in any module, which modify the the tree of
   files after it's fetched. These made an appearance in the fancy example
   above:
-  - `build`: A shell command to run on the fetched files. Fetching happens in a
-    temporary directory, and this command will be run there.
+  - `build`: A shell command to run on the fetched files. Fetching happens
+    somewhere in outer space (a temporary directory), and this command will be
+    run there.
   - `export`: A subdirectory that peru should treat as the root of the module
     tree. Everything else is dropped, including parent directories. Applies
     after `build`.

man/peru.1

@@ -1,21 +0,0 @@
-.TH PERU 1
-.SH NAME
-peru \- a modular build tool
-.SH SYNOPSIS
-.B peru
-[\fB\-\-version\fR]
-\fICOMMAND\fR [\fIARGS\fR...]
-.SH DESCRIPTION
-.B peru
-builds multi-homed modules and dependencies
-.SH OPTIONS
-.TP
-.BR \-\-version
-Prints version information.
-.SH COMMANDS
-.TP
-.BR pull " " [\fB\-\-flush-cache\fR]
-Pulls source code and cached binaries to the local workspace.
-.TP
-.BR build " " [\fB\-\-flush-cache\fR]
-Builds the local workspace.