get rid of the toplevel 'plugins:' field

Summary:
This feature didn't turn out the way we liked. It would be neat if
modules could fetch their own plugin definitions, but that would require some
kind of early fetch, so we went with a static version that requires checking in
plugins. But even that was going to cause a lot of complexity when we enable
recursive projects, which would involve unpacking the calling tree every time a
submodule was fetched.

Instead, we're going to fall back on the simpler design, where plugins have to
be installed on the user's system before they're used, just like peru itself.
Eventually we'll add plenty more levers for this, like default plugin dirs for
the system and for the user, and some env vars to extend that.

Test Plan:
Tests related to the plugins path have been deleted. We'll need to rewrite them
when we have those levers. Arguably we should have some more tests that
directly exercise the lower level methods of plugins.py.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D63
remove the 'build' command

Summary:
`peru build` was an interesting idea, but the more we think about what it will
need to support, the more it looks like it'll require a lot of complexity
without a lot of benefit. Peru doesn't get in the way of source control because
it doesn't have to know anything about it. That's a good design decision.
`peru build` feels like the opposite, like peru needs to know all about your
build system. That looks more and more like a mistake.

`peru sync` has the nice property that it involves very little state. You're
either synced, or you aren't. You don't need to worry about *which*
dependencies you've synced, etc. Build commands, on the other hand, tend to
have a lot of state. You might want to build particular targets (`make debug`
vs `make release`) or pass any number of options to the build system
(`make -j 8`). We really don't want to wrap all this functionality, because
we'll inevitably do a crap job of it and just end up making it harder to use
your tools.

This diff gets rid of the build command entirely. For projects that want to
sync and build, the preferred approach will be to have the build scripts call
peru, rather than having peru call the build scripts. The 'build' field at the
top level will no longer have any meaning until we introduce recursive
projects. (The same was always true of 'export' and 'files', so if anything
this is more consistent.)

We'll need to think a little more about how things should work in recursive
projects. For example, if a build tool in a module calls peru again, should
that Just Work? Or should peru be aware that it's running recursively and
behave differently? Thoughts for the future.

Test Plan:
The build command integration test included some important cases of
rule chaining in local modules. Move those to a new overrides test.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D64
prefer "module" over "plugin" when describing reup

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D80
check the version of python in bin/peru

Summary:
This happens before we import the peru libs and hit a bunch of sytax
errors on older Pythons. We'll need to keep `bin/peru` backwards compatible,
but that's fine since there should never be any significant logic in there.

Test Plan:
Try to run peru from a python3.2 and python2.7. Get a clean error in
both cases.

Reviewers: sean

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