create the "plugins" field for user-defined plugins

Summary:
Extend the interfaces in plugins.py to take additional plugin paths, and plumb
this all the way up. Make sure plugins are resolved relative to the project
root (in runtime.py) and not just blindly assumed to be valid paths. This field
shouldn't be able to change the behavior of existing modules, so if the same
plugin is ever defined twice, raise an error.

The complexity of this diff raises a couple of design issues that we need to
think about:
- The plugins.py interface is getting very complicated. Should we encapsulate
  it in some kind of config object? Should it take a `Runtime`? (This would make
  it difficult to unit test.)
- Allowing users to run peru from directories other than the project root is
  creating complexity throughout the code. The kind of path massaging that we
  have to do here in runtime.py is very easy to get wrong, and very easy to
  miss in testing. We really don't want to burden every new feature with a test
  to make sure it handles funny dirs. Is there a way we could make this kind of
  testing automatic? Should we use chdir magic to make paths Just Work? (That
  would make resolving paths in peru.yaml easier, at the expense of resolving
  paths given on the command line.)

Test Plan: Lots of new unit tests and an integration test.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D27
add the 'files' field to rules and modules

Summary:
For a while now we've been using `build` rules to handle file filtering, by
copying files into an out directory and then exporting it. That's pretty hacky,
and it's worse when it needs to be portable. The new `files:` field replaces
these hacks with native globbing from `pathlib`. These globs are resolved
relative to the `export` path.

Also update our peru.yaml file to take advantage of the new field.

Test Plan: New unit test for `Cache` and integration tests for `Rule`.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D30
allow `peru help`

Summary: I constantly type that when I meant `peru --help`.

Test Plan: Created an EC2 cluster and ran a few hundred thousand test passes.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D31
clean up Cache exceptions

Summary:
These should inherit from PrintableError so that we don't have to
catch them on the way up. This makes it easier to look for specific exceptions
in integration tests. Used in the following `peru clean` diff.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D32
create `peru clean`

Summary:
Deleting your imports will make peru yell at you the next time you try
to sync. Usually `git clean -dfx` works for us, because it also deletes the
`.peru/lastimports` file. But not everyone can just run `git clean`
willy-nilly. They might not be using git at all, or they might have other
uncommitted files (like IDE metadata) that they don't want to nuke. Create the
`peru clean` command to make clearing out imports easier. (And safer!)

Test Plan: New integration test.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D33
fix tests that were cluttering the repo with temp files

Summary:
We were using relative paths in a few tests that made files get created in the
peru repo itself. Gross. Clean these up. Add a check in `test.sh` so that we
will notice if this happens again.

Test Plan: Run the new `test.sh` with the old master. Observe failure.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D34
stop requiring realpath

Summary:
Most systems don't have `realpath` by default.  Right now the only other
dependencies you need to run peru from the repo are python3 and git, and
keeping it to just those two would be nice. (Note that running tests requires
other stuff.)

The only script that actually needs `realpath` is `peru.sh`, because that's the
only one that needs to support being run from a symlink. Use the pure bash
version from http://stackoverflow.com/a/1116890/823869.

Test Plan:
I can still invoke peru from my `~/bin/peru` symlink. The `test.sh`
and `validate_third_party.sh` scripts still work from outside the repo.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D35
add the optional 'list' subcommand to override

Summary:
Like `git branch`, `peru override` just lists existing overrides if
you don't give it any further arguments. For clarity, though, it would be nice
to also support `peru override list`. Because of the way our command parsing
works, adding this is actually trivial. As long as docopt allows it, it will
fall through to the existing `peru override` handler.

Test Plan: Extend the override integration test to check this.

Reviewers: sean

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