Typed emission

Currently, the "response emitter" has a single `Emit` function that magically determines the right thing to do. Unfortunately, this is *really* magical:

1. We have a special "single" wrapper to inform HTTP that we're emitting a single value.
2. If the user "emits" a reader, we copy it as a stream of bytes.
3. If the user emits normal values (not `Single`, we emit a stream of values).

This is getting better with the next iteration of the commands lib (this list *used* to include errors) but it could be improved.

Solutions:

1. Have different command types. While the nicest from a type safety standpoint, this may not be the friendliest option.
2. Apply a type-switch to the command's Run (and PostRun) functions. Personally, this is the one I'd vote for.

In the second case, we'd allow the following `Run` signatures:

```go
// Writes a stream
type StreamFunc func(req *Request, resp io.Writer, env Environment) error

// Streams items
//
// We can keep this "magical" for now but eventually remove the magic and force users to use the other variants.
type EmitterFunc func(req *Request, resp ResponseEmitter, env Environment) error

// Sends a single item
type SingleFunc func(req *Request, env Environment) (interface{}, error)
```

Thoughts? This should make sending HTTP responses simpler and will likely improve user experience.

Start by reading the response emitter and the command Run and PostRun paths described in the issue. Compare the proposed StreamFunc, EmitterFunc, and SingleFunc signatures with the current emission behavior, then determine which design the project should adopt. Done means the chosen approach is implemented consistently and its response behavior is covered by tests.

Written by the indexing model from the issue text.