Environment

Introducing `Lotus::Environment` as abstraction for Lotus env vars and for the options that the CLI receive.
When initialized, it sets the following env vars:

* `LOTUS_ENV` and `RACK_ENV`
* `LOTUS_HOST`
* `LOTUS_PORT`

It should be used by all the CLI commands and by `Lotus::Configuration`.

**Use case:**
When we use `lotus server --port=4000 --host=testhost.org` we expect that the application's router respect those settings.

**Constraints:**
We want the application to be _self loadable_. In every place when we do `Bookshelf::Application.new` the application should be ready to be run. Think of a simple `config.ru` where we require the app and we just write `run Bookshelf::Application.new` and it works.

**Alternative A (current implementation):**
_Scenarios_:

* When the application is started via `lotus server/console`, we initialize `Lotus::Environment` which reads CLI options and sets the env vars. Once they're set, a new instance of `Lotus::Environment` is created by `Lotus::Configuration` and we can access those values.

* When the application is started via another command (eg. `rackup` or `puma`), we don't have direct access to the CLI options, but we can read the env vars from `Lotus::Configuration` via `Lotus::Environment`.

* When the application is started via another command, and the env vars aren't set, we rely on the manual configuration (eg. `Bookshelf::Application.configure { port 1234 }`), otherwise we fallback to the default values.

_Pros:_

* We keep the constraints satisfied

_Cons:_

* We communicate via env vars

**Alternative B:**
_Scenarios_:

* When the application is started via `lotus server/console`, we read the env vars and the CLI options and we inject a complete configuration into `Bookshelf::Application.new(configuration)`

* When the application is started via external commands (eg `rackup` or `puma`), it relies on the correct manual `config.ru` configuration.

_Pros:_

* We communicate via message passing (pure OOP)

_Cons:_

* The constraints aren't satisfied because an application always need external loading mechanisms before to be instantiated.

* It complicates `config.ru` setup. Even if we generate that file, it may require future maintenance if the loading mechanisms will change. Better to protect developers from those changes.

* It requires complex tests setups every time we want to unit test an application

* When we start `lotus server/console` we don't know yet the `Lotus::Application` subclasses. We should implement a registry in order to instantiate applications. Because Ruby's `require` isn't thread safe, in multithreading environments like JRuby, Rubinius, it may be lead to subtle bugs.
@davidcelis You should consider that fixtures only as test data. They were put there before we started discussing about the console, and about the structure that we want to shape with the code generators.

That applications in `test/fixtures` aren't run via a `lotus server` or `rackup`, but via `rack-test`, which doesn't spawn a separate process for them. At that level we assume that the application container behaves correctly. That's why they miss the `config.ru`.

Speaking this file, it's [required](https://github.com/rack/rack/blob/master/lib/rack/server.rb#L124) by `Rack::Server` which is the superclass of `Lotus::Commands::Server`. So we want to allow to the users of `lotus server` to specify a different path.

For `lotus console` I'd suggest to have a default file like `config/applications.rb` where we require all the Lotus applications. So that `console` isn't concerned by the configurations that `config.ru` may contain.