Merge branch `spelling` into `master`.
Merge branch `failed-assertions` into `travis-ci`.
Abend when test is repeated for a test run.

Throwing an exception when a user specifies a test program more then once for a
test run. This would throw off the timing and reporting, because we group that
by the name of the test. Each test should be a simple program that tests one
thing, not a complicated program with command line switches or some other way of
changing the programs behavior between invocations.

If you do have repetitious tests, instead of creating a single program with
different modes of operation, create tiny programs that require a common module
and fire off a function with some parameters.

With this in place, there's no need to include the process ID in the raw output,
so this closes #4 as invalid.
Created `errors` to display error output.

Problem with errors is that output can be interleaved, so we need to gather up
the lines of output after a failed assertion, or else the output of other
assertions get interleaved.

The first formatting style that comes to mind would be one that grouped all the
failed assertions under their failed test, but that means waiting for a full
test to load. There are test with a great many failures, one of the automated
tests, like the one in Timezone that tests every clock transition in the world
since the dawn of standardized time. We might run out of memory if a test of
that nature is really broken and really chatty about it.

What we're going to do for a stab at this problem is create a queue, as we do
with progress, and one go at a time. Chances are the queue will be empty. If
there is one long running test interleaved with a quick test, then the quick
test will be done quickly, and the long running test can take over.

If two long running test are interleaved, then we might want to view the tests
one at a time by piping the test through grep to limit the output inspected, or
else piping it through sort so that the rest results are not interleaved.

Related to #5. I'm not sure if I want the progress runner to display errors,
actually. Progress is one thing, errors are another.

The progress runner probably does have to display errors  I'll weave the
`errors` output into it once I'm happy with how it looks.
Set width and width of timings.

Added a `--digits` parameter to `proof progress` and to the default invocation
of `proof`. It sets the number of digits of the time display. This excludes the
decimal point, which is not a digit. The display always has a millisecond
readout. `4` is both the default and the minimum.

Added a `--width` parameter to set the width of the display in characters. Fixed
the `fill` function to return the correct number of fill characters, it was
returning two less than requested.

Closes #16.
Closes #19.
Failure on error exit, using expected tests.

Fixed a bug where tests were being marked as passing because the
condition for passed tests was whether passed matched actual, which
would cause a test to pass even if not all of the expected tests where
invoked.

Now reporting as a failure test programs that exit with a non-zero exit
code.  This covers the case where tests do not even start because the
test will not compile. In this case the expected and passed assertions
are displayed as zeros, and the test is displayed as a failure. It ought
to be pretty obvious that the test wasn't able to do anything.

The failure of a test program due to a non-zero exit code propagates to
the test run summary.

Closes #6.
Closes #8.
Code tidy.

Felt that I was using the word `program` too much, especially when it
was used to describe an event emitted from a program. Thus, I've
replaced the variable name `program` the the name `event` in a lot of
places.

I was using the fantastically ambiguous variable name `record` to
describe events, so that has also changed to `event`.

Renamed the function `styling` to `bar`.
Unfancy error format.

Set out to create an indented format, but that started to get annoying.
Rather leave the output flush left making it slightly easier to copy and
paste.

If someone wanted only the error output, they could write their own
errors utility using `awk`. Actually, that would be hard. You would need
an error format that annotated each line with the test and failed
assertion name. I might consider making something along those lines, if
the formulation of utilities using bash draws me in.

As it stands, I'm not going to emit assertions from the progress
formatter. That would ruin that display. When you want to see errors,
you can run `proof errors` against the `proof run` output.

Closes #5.
Merge branch `failed-assertions` into `travis-ci`.