overhaul of the response writing flow

As mentioned in the commit msg, it depends on landing [PR 55](https://github.com/chris-morgan/rust-http/pull/55) landing on rust-http. How you choose to integrate this into your local fork is up to you (also note that @chris-morgan has fixed the issues w/ from_utf8 and Option<~str> in his repo).

So I took a stab at overhauling the response-writing workflow. I still ended up using a trait object, but only to encapsulate the differences between different `ResponseBody` types within the generated router code (which now emits a ~ResponseBody). There are now a few `impl`s of `ResponseBody` that are separate types. This was to avoid ackwardness around having to parametize all instances of `ResponseBody`, when only the `JSON` variant would take the parameterized type. I hope this solution is sufficient for you.

There are a few optimizations to be made in here, if you choose to accept it. There are some FIXME's in servlet.rs , mainly, with the approach to how I chose to impl it (writing the resp w/ ~str instead of writing a byte buffer). Also the stuff around content-type can be beefed up (text response should probably have to indicate what its content-type is).

I also switched from returning numeric status codes to using `rust-http'`s `Status` enum. I don't know if your goal was to complete encapsulate `rust-http` within `feral` because, if so, then this needs work. I felt it was easier than basically re-implementing `Status`, though, just to avoid a module import.

Anywho, I got this building and ran the server and verified that it returns responses (although I didn't test the file downloading stuff).