Event reporters and many fixes (tests on the way)

Fixes #26, #23, #17, #7, and #3

I've been working on improving things and adding features that I needed. (With the changes here, I no longer need to use the js api, I can simply use the cli).

There's a lot, and it's not finished yet (namely: refactoring and coverage), but I wanted to put it up for review/feedback so that it's mergable quality.

### Overview of changes
#### Reworked reporter system
  - Reporters use events now
  - There are many more reporters (cli, dot, nyancat, junit, markdown, and there's a stub for html)
  - Reports have duration times
  - Junit reporter writes asynchronously
  - Errors are aggregated at the bottom 

#### Reworked CLI
  - The cli library couldn't do enough, so I switched it to optimist, which allows, among other things, multiple parameters with the same name
  - Can now pass in headers as parameters, with `-h` or `--header`, and can be used multiple times.
  - Similarly, can pass in multiple reporters and multiple output paths (you can use the nyan reporter to view in the console, while also outputting to junit and markdown, for example).
  - Can filter the requests by http method, with -m. E.g. `-m GET -m POST` will only run the GET and POST transactions defined in the blueprint.
  - Can choose to show errors inline with `--inline-errors`
  - Can pass in basic auth credentials with `-u` or `--user` e.g. `--user bob:test`. (This is the convention used by curl)

### Still To Do

- Usage output isn't formatted very well at the moment.
- There should be a `--no-color` flag that is respected throughout the app.
- The `--verbose` flag should actually output debug info
- And, of course, tests and coverage. (I decided not to go TDD with this one, and am regretting it)

### Things I want to do which can't be done yet

- The reporters should be aware of groups and other structure from the blueprint. This isn't *easily* done right now because the parsing is separate from the transaction execution. Either this information should be embedded in the transactions, or the transactions should execute as the blueprint is parsing.

- Multiple request/response pairs. This would be easy if the blueprint format supported naming Responses (you can only name Requests right now) - it could simply pair them by name. As it stands, there's no way to tell which response goes with which request.


![](http://f.cl.ly/items/363r250B3p3Y1S1P3I05/Screen%20Shot%202014-01-07%20at%205.39.35%20PM.png)