A better console for --develop

__tldr;__ Create an interactive console for use when developing. Instead of being a log of everything that happens on the server, it would group information by what you are more liking to care about.

> This was discussed on a [recent live stream (54:58)](https://youtu.be/ieZJrPwSZYQ?t=54m58s) and at a [contributors meeting (51:24)](https://youtu.be/95OX6-qii24?t=51m24s)

# The Problem

When running `donejs develop` in your console you will see a log of __all__ activity that happens on the server. This could be:

* Warnings generated within canjs.
* File changes that cause a live-reload event.
* Errors when you do a typo.

And many more. It's not very attractive and looks like this:

# The Solution

Create a new console interface that better serves the user. I would:

* Have more of a curses look. So not a scrollable console.
* Segregate live-reload messages to one section / box.
* Have an area for generic error messages.

A proof of concept of this exists in the [curses branch](https://github.com/donejs/done-serve/compare/curses) of done-serve. Here is a demonstration of what that looks like:


# Implementation

We would like to make it possible for users to create their own UIs. We can see some exciting UIs such as:

* An interface that connects to the browser, so that messages appear there while the user works, similar to [figwheel](https://github.com/bhauman/lein-figwheel):


* An interface that connects over a network, so that you might have your development server running on an external server and controlled remotely.

# API

## `--ui `

I propose adding a new flag to done-serve, `--ui` which allows specifying an alternative UI library.

It will load the npm module `done-serve-ui-` and communicate with it via an [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter).

The default interface, the one that just logs everything to the console like today, could be implemented like so:

```js
module.exports = function(events){
events.on("log", function(msg){
events.console.log(msg);
});
events.on("error", function(err){
events.console.error(err);
});
events.on("live-reload", function(msg){
events.console.error(msg);
});
events.on("server", function(url){
events.console.log("done-serve starting on " + url);
});
};
```

## Possible UIs

Depending on what the users want, we could start building one of these UIs. Make your opinion be heard!

## done-serve-ui-curses

This would be the first UI I would build, and it would be a curses interface similar to the one from the proof-of-concept. Several other ecosystems have developed similar interfaces. I think the things users care about are:

* Errors. We should make an effort to make these as clear as possible, so extracting stack trace information and displaying it better would be a major win.
* live-reload: You want to know which files are being reloaded, so if you don't see a change you expect in the browser you can look to the console to see if the module has live-reloaded yet or not.
* Statistics: Things like file sizes, API request times, and anything else that could be used to fine-tune the application.

## done-serve-ui-web

This would be similar to figwheel as explained above. This would require the user inject something (maybe a can-component?) into their page, which would display the information. From there the `done-serve-ui-web` package would communicate over websockets to display all of the information.

No source files or tests are named. Start by reviewing the done-serve curses branch and the proposed --ui interface using EventEmitter, then trace how log, error, live-reload, and server events are currently exposed. Done requires an agreed first UI scope and a verified extension path.

Written by the indexing model from the issue text.