move reup output to PERU_REUP_OUTPUT

Summary:
Previously we've allowed plugin fetches to print progress directly to stdout,
but used the stdout of reup to get the actual reup data. This is kind of
inconsistent, and with the upcoming fancy console display, we're going
to want reup to print progress to stdout the same way fetch does. We'll
need a different channel for reup's actual data output.

Create the `PERU_REUP_OUTPUT` variable, which is defined during reup to
point to a temporary file where the plugin should write its
YAML-formatted result. Conceptually this is similar to the
`PERU_FETCH_DEST` variable already used for output during a fetch.

For now, discard the stdout from reup but allow the stderr to print to
the terminal. In the future, we'll do the same thing with stdout here
that we do in a fetch.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D89
[WIP] fancy job display

Summary:
Create a multi-line terminal display that shows output from plugin jobs
in real time. This requires reworking the way plugin jobs deal with
subprocess output. They now take an "output handle", which is a
buffer/context-manager that implements `__enter__`, `__exit__`, and
`write`. Jobs receive these handles from a "display" object that lives
on the `Runtime`, and they write to the handles inside a `with` block,
which lets the display know exactly when jobs start and stop.  The
plugin tests also include a dummy handle implementation, which is a thin
wrapper around a `StringIO` buffer.

In addition to the default `FancyDisplay`, there is a `QuietDisplay` and
a `VerboseDisplay`. The quiet one prints nothing, and the verbose one
waits until each job is finished to print all its output to the terminal
in one go (so it's not real time, but it's formatted in a way that's
suitable for log files). Errors from plugin jobs are handled by throwing
`PluginRuntimeError`, a subclass of `PrintableError`, so the displays
don't need to do anything special.

The fancy display would like to draw to the terminal as soon as it gets
output from a job, but with a few git clones running in parallel that
starts to cause unacceptable flicker. My solution right now is to draw
on a 0.1 second delay, so that a ton of updates coming in at once get
coalesced into a single draw. The main downside of this approach is that
it makes `FancyDisplay` depend on the asyncio event loop to implement
that delay. I'll probably have to hack around that to write tests.

TODO: Write unit tests for the different display types. Make hg, svn,
and curl print progress to the terminal (right now only the git plugin
has been brought up to speed).

Test Plan:
The plugin tests use `TestDisplayHandle` to work with the new interface.
Still need to write serious unit tests for the displays, which will
probably involve creating a little terminal simulator that knows how to
interpret the ANSI control codes we're using.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D91
remove remote module imports

Summary:
Since early on, we allowed remote modules to have imports just like the
toplevel module does. We envisioned peru running serious builds for you
and giving you the build products, and we wanted to support builds that
had dependencies on other modules. More recently we've come to the
conclusion that having peru wrap real builds is a bad idea. See
d374aa4d5415b658565e474143681f1bc0fae411, where we removed the `build`
command. This diff removes remote module imports for the same reasons.
We were never using them in practice, and they also made overrides more
complicated.

Closes https://github.com/buildinspace/peru/issues/48.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D92
add context to module field error messages

Summary:
We have several important checks (like invalid module field names) that
are still `assert`s from back before we had any kind of UI. Replace
these with proper `PrintableErrors`, and include maybe-kinda-sorta
important information like the name of the invalid field.

I'm removing the check for whitespace in plugin field names. If the
plugin author wants to define a field with space in it, that's now
possible, though we should consider supporting it a little better. See
https://github.com/buildinspace/peru/issues/51.

Test Plan:
I exercised all these errors by hand to make sure the printouts looked
good. I've added actual tests for some of them, to confirm that field
information is actually present in the message.

Reviewers: sean

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