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`. Even though just
`peru` does the same thing, and `peru help` isn't strictly needed, we should be
generous with help. Eventually we'll want this anyway for command-specific
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.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D34
expand README.md

Summary:
I'm fond of the tagline "maybe sometimes better than copy-paste", but we should
definitely settle on something we both like.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D22
more