lib: refactoring

Here comes the refactoring of the lib part. It passes all tests and passes `jshint` and `eshint`. `eshint` helped me with `"` vs. `'` and `==` vs. `===`.

This refactoring tries to stay true to your original implementation.

My plan for the next step would be to make the api exposed match the one provided by the builtin `http` module. This would allow the usage of modules like `connect`, `express`, `router`, etc which I think would be very cool! It will also spare the user of some boiler plate code setting up the `net.Server`.

This would involve two steps.

First, make message a stream and emit it as soon as the headers are parsed. Then stream the rest of the body to the message. I think that this is quite good in itself since it is dosen't require buffering the whole body up, it would however be good to also expose api that buffers everything and provide a nice string for the user.

Implement a server and change some event names to match the http module. Basically just reworking the glue to expose the proper api.

What do you think of this roadmap? Does it sound interesting for you? I would of course like to keep the module as simple to use as it is now, not forcing anything unnecessary onto the library users.

~~(this pq includes #4, if you pull that one first the first commit from this one should disappear)~~
To clarify, are the groups matching: protocol name, status code, and message in that order?

Shooould we assume that status codes are always numeric? (I think the answer is yes, and I can't of any obvious examples where this wouldn't be true)