Alternative command implementation

These are just some thoughts about an alternative way to implement commands, no actual implementation done. It might be overkill, result in a weird API, or plain unnecessary, but I might as well post this here. Idea came after reading this [introduction to frp](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754). I hope this is not just incoherent mumbling, but actually understandable.

Basic concept: Commands communicate via frp streams. Each instance of a command has an input stream and an output stream. When a user types and activates a command, an instance of the command is created, based on the given options. The actual argument is not used in the creation of the command instance. Then, the argument(s) are passed to the command's input stream. The command does some stuff, then writes the output through it's output stream. The output stream is listened to by vorpal, and by default the output is printed into the console. When the command is done, it ends the stream, which vorpal interprets as if the command's callback in the current implementation was called, returning focus to the user.

Command piping could easily be implemented by piping the output stream of the first command into the input stream of the second one. Unlike the current implementation, commands would run asynchronously. This way, two commands separated by `;` could be started simultaneously.

Commands could also emit errors. This would allow implementing `&&` and `||` for command chaining. One could even go further and use `2>>` to only pass on errors etc.

Parsing a command string from the user could be done in two stages: First, separate actual commands and chaining operators via regexes. Second, create command instances and correctly chain the streams together. By separating this, parsing the command options could be delegated to one of the existing node modules.

_edit_: Parsing using regexes is **not** a good idea...

Command definition would be done by giving methods handling arguments from the input stream, errors from the input stream, and end of the input stream (vorpal could provide a sensible default for errors and end of stream), instead of `command.action()`.

Pros:
- asynchronous commands
- well structured command parsing
- clear implementation of various piping and chaining possibilities
- well testable

Cons:
- slightly more complex API
- API breakage? (The stream based implementation can simulate the current one, so maybe not)
- Vantage integration?
- Complete rewrite of a lot of code needed

I currently don't have time to spend on this, but I wanted to get the idea out there. And if this is not just garbage, I could start working on this later - no need to hurry...