Environments and assets

This PR is a proposal of changes addressing two main areas:

- Environment aware configuration
- Asset concatenation and minification

### Environments
The first thing i needed after cloning and tampering, was deploying. A common need is to load different configuration variables and settings depending on the environment the app is running in.
The PR addresses this by:

- Make `app` a global variable. While this is tipically a bad practice, it's unlikely someone is going to overwrite `app` in an Express setup. The payback is that `app` is available to every required module; 

- Extending `app.settings` requiring a file with the same name of the current environment (`development` by default):

        // app.settings.env is 'development' by default, 
        // or the value of process.env.NODE_ENV if it's available.
        _.extend(app.settings, require('./config/' + app.settings.env));

- Modify controllers to load configuration from app.settings;
- Move passport.js to `/initializers` (à la Rails: modules which not only specify settings, but execute logic dependent on settings, normally _initializing_ other modules)

### Assets pipeline
It's a common practice to have some sort of concatenation & minification tool for deploying to a server.
`connect-assets` basically mimicks Rails Asset Pipeline by introducing _manifest files_ which list resources to be packed (normally, css and js).
The PR addresses this by:

- Moving js and css assets to `/assets`, while leaving `/public` for assets to be treated as plain static files.
JS and CSS files should always be put in assets, while public should be used for fonts and images.
- Add `connect-assets` middleware
- Set `build=false` in the options passed to `connect-assets` for the `development` environment.
- Use `!= js()` and `!= css()` helpers to load assets inside views

Sidenote: it's still fully possible to load single js or css files by passing the path to the != js() call.