refactor tunnel middleware into two phases

By splitting the tunnel logic into a detection phase and a handling phase,
applications are free to override the handling logic.

In order to maintain backwards-compatibility, instead of refactoring the
existing tunnel middleware, a tunnel-demux middleware to detect the type of
tunnel request, and tunnel-(rpc|specs|type) middleware to handle each type of
request have been added. Mojito itself will now use these new middleware in
place of the single tunnel middleware, which will remain for those applications
that are specifying it in their configuration.
implement feedback from pull #1044

- delay object creation for performance reasons
- use core library methods for parsing url/path
- fix http response code (500 => 404)
- eliminate `that = this` usage by closing over prefix variables directly
clean up the logic around path inspection

- Replaced the brittle `trimSlash` stuff with `require('path').normalize`.
replace tunnel middleware with refactored version

- Remove trailing slashes from tunnel/static prefixes.
- Add flag and flag check to determine when to stop processing the request.
fix bug where configured prefixes can be undefined
fix test mock and remove unused variables
execute tunnel middleware as an async queue
streamline middleware error handling

Uses the convention where a middleware with an arity of 4 is assumed to be the
error handler.
initial unit test commit for refactored tunnel middleware
simplify response logic with express response sugar

With unit tests!
Merge pull request #1044 from ekashida/tunnel-refactor

refactor tunnel middleware into two phases