Add lotus binary

Adds a `lotus` binary. Currently uses thor to parse arguments etc but could easily be changed in the future. Right now this only adds 1 useful command: `server`.

### Output
```
ᐅ bundle exec lotus
Commands:
  lotus help [COMMAND]  # Describe available commands or one specific command
  lotus server          # starts a lotus server
ᐅ bundle exec lotus server
[2014-06-27 23:47:55] INFO  WEBrick 1.3.1
[2014-06-27 23:47:55] INFO  ruby 2.1.2 (2014-05-08) [x86_64-darwin13.0]
[2014-06-27 23:47:55] INFO  WEBrick::HTTPServer#start: pid=27677 port=9292
```

### Misc
I also tracked down and figured out the cause of the content length issues in Safari. So this pull request also fixes #5 assuming someone starts the server using the `lotus` binary.

### Further work
Obvious further work includes things like:
* Lotus app generation similar to `rails new`. Would need to support the basic app structures laid out in the readme as well as a blank structure.
* Add a `lotus console` command.
* Live reloading. I think the best strategy for this is to use a forking option like in the shotgun gem. At least in the short term.

I'll probably attempt to tackle the second two options. I'm less fussed about the app generation command although I do think the binary should do something useful outside of a lotus application.

### Discussions
* Should we default the lotus port to 3000 or to something else?
* What other items would be useful to put into a `lotus` command?


With `ARGV.slice`, `Lotus::Commands::Server` works on several levels of abstraction. We should isolate this object from the CLI arguments, by letting `#initialize` to accept always accept options. I know that this is due to the poor Rack [implementation](https://github.com/rack/rack/blob/master/lib/rack/server.rb#L178-L185).

I'd suggest:

```ruby
attr_reader :options

def initialize(app, options)
  @app, @options = app, options
end
```

We use Thor with the purpose of having a better control on CLI. Let's use it and protect our users with an abstraction ([Dependency Inversion](http://en.wikipedia.org/wiki/Dependency_inversion_principle)), from the changes that Rack may do in the future.

I'd love to see `Lotus::CLI#server` to pass as constructor argument, the proper application.