Synchronous harness definition functions.

This fell out of converting the tests in Stencil from Stencil's current test
framework to Proof. I had created a wrapper around a `deepEqual` assertion,
called `scanEqual`, that would compare some Stencil code against an array of
tokens, after the code had been run through the scanner. It made my tests a
little less verbose to wrap the scanner call in a helper function along with the
assertion call.

To define this function in a Proof harness, I'd need to have access to the
special `deepEqual` in the Proof `Test` class, so that it would emit the
correctly formatted output to standard out. The update that implemented
`@cleanup` did so by calling the harness definition function with the soon to be
run `Test` object instance bound to `this`. The same `@cleanup` function
implementation could then be used in both harnesses and tests.

Now the `@deepEqual` method with its correctly formatted output is similarly
available to the harness definition function. To create my `scanEqual` method I
simply needed to convert my harness from one that defines the harness context
with a context `Object`, to one that defines the harness context with a
callback function.

However, it turns out the harness generation bits of the library were not
expecting synchronous callback functions. The callback was given a `function
(error, result) {}` style callback that it did not itself call.

This commit allows synchronous callback functions for harness definition. It
also starts an `API.md`, where I made a note of this detail, since it is going
to be one detail to many for the `README.md`. Eventually, `API.md` will contain
dry, function by function reference for Proof. For now, I'm dropping notes in it
on implementation details that do not fit the narrative style of `README.md`.

This commit also makes me wonder if context definition using a context object is
necessary. It would be less code, and more concise documentation to have only
the definition function.

The definition function could even provide a context object to populate, making
it much like the `module` object in the `require` module definition framework,
and saving our friends a line of code to create the context object.

It is pretty easy to do `{ one, two, other }` as a return value in CoffeeScript,
however. I'll have to write some more harness definitions functions to decide.
Default harness name, other naming conventions.

Changed the default harness name from `harness` to `proof`. This allows us to
continue to say `require("./proof")` when using harnesses, which is very clever.

Removed the need for a shebang line at the start of the harness. This was used
to suggest a shebang line for new tests when the test generator was run. Instead
we check the file extension of the harness. If it is a Streamline.js file
extension, or if `_` is given as a parameter to the test generator, then
`_coffee` is used as the executable in the shebang line. Otherwise, `coffee` is
used.

Updated `README.md` to remove shebang line requirement.

Renamed `require("./harness")` to `require("./proof")` in all code examples.
Also, fixed a missing shebang in one of the code examples.

In the course of this, I'd forgotten that this is for CoffeeScript. I'd
forgotten that the harness I'm generating is a CoffeeScript file. I'd have to
make a decision to generate JavaScript and Streamlined JavaScript that I've not
yet made. I do look for a possible `.js` or `._js` file extension on harnesses,
but I do not offer the option to generate a JavaScript test program.