Middleware phases - initial implementation

Modify the app and router implementation, so that the middleware is
executed in order defined by phases.

Predefined phases: 'init', 'routes', 'files', 'final'

Methods defined via `app.use`, `app.route` and friends are executed
as the first thing in 'routes' phase.

API usage:

    app.middleware('init', compression());
    app.middleware('init:before', serveFavicon());
    app.middleware('files:after', loopback.urlNotFound());
    app.middleware('final:after', errorHandler());

Middleware flavours:

    // regular handler
    function handler(req, res, next) {
      // do stuff
      next();
    }

    // error handler
    function errorHandler(err, req, res, next) {
      // handle error and/or call next
      next(err);
    }

See also:
 - The discussion in #757, especially my [last comment](https://github.com/strongloop/loopback/pull/757#issuecomment-62140861)
 - #739 (the work item)
 - A pure express solution prototyped by Doug: [gist](https://gist.github.com/dougwilson/16d44df4036f19a2c0b1) 

**Out of scope - will be done later**

 - More predefined phases
 - API for adding custom phases
 - Draft of Confluence docs

/to @ritch @raymondfeng please review
/cc @fabien @superkhau 
This is out of scope of this PR, at least in my intentions.

Once this is landed, I want to implement a function for adding arbitrary list of middleware phases, the implementation will use a merging algorithm under the hood.

Mockup:

```js
app.registerMiddlewarePhases(['init', 'auth', 'routes', 'subapps'])
// app phases are now
//    'init', 'auth', 'routes', 'subapps', 'files', 'final'
```

This new API can be used by loopback-boot - `middleware.json` can specify a full list of phases, and loopback will intelligently merge that list with the built-in phases to produce a single list of phases satisfying both loopback and the app.

Compared to your solution, my solution should be more flexible, but it does now allow users to remove predefined phases. If you feel that we should allow users to remove predefined phases, then I can implement API for that in a different PR. However, I'd rather not remove phases until we have a clear scenario where this is a must. The drawback of removing phases is that loopback core can no longer rely on the fact that a well-defined list of phases is always available.