Comparison with Tumau for potential collaboration / merge

Hi,

I'm writting a very similar software [etienne-dldc/tumau](https://github.com/etienne-dldc/tumau) so I think it would be interesting to compare the two to see how they differ and if we could merge them into a single project.

**Note**: I'm just writting the thing I can think of right now with my understanding of `srv`, this is probably incomplete and possibly wrong. If anyone want to add things / correct me feel free to do so.

## Context

While `srv` does not have a concept of Context `tumau` has one. The reason behind this choice is that there are things that are not really related to request like authentication, external api... In fact in `tumau` the Request object is just there for typings really. And so if you want to parse JSON for example, you have to use a middleware that will parse the req as json and populate the Context so you can access it in other middlewares.
The drawback of this approach is that you have to type the context for your entire app (too complex to type for each middleware). So in the case of the JSON parser middleware you would type your context as `{ json?: any }` and then you have to make sure the `json` key is populated before using it.
But in practice this is fine, in fact i'm quite satisfied with this.
Also note that the context is expected to be immutable. If a middleware want to change the context for the next one it need to pass it to `next` and/or to return a new context.

## Middleware

The Middleware definition is a bit different, mainly because of the context.
The main differences are:
- The middleware receive `(ctx, next)` as argument (the `request` is in the context)
- The `next` function take a `context` as parameter
- A middleware can return an object `{ ctx, response }` to change the context on the way back
- The next function return a Promise of an object `{ ctx, response }`

## Routing

In `tumau` routing is not part of the core bundle but in a separate one `@tumau/router`.
One of the main trouble I had while developping routing was to combine namespace (or prefix) while making the OPTION -> `Allow` header work...
This constraint explain most of the router API.

## Debug

`tumau` does not have a debug system, but that's clearly missing !

## Test / Benchmark / Repo

- `tumau` is a monorepo (it was a bit hard to setup but I think it's OK now)
- I've made a custom Jest matcher to snapshot HTTP Response Header (and a custom request runner)
- I've tried to setup a benchmark but I'm not sure it's relaible...
- I haven't setup a CI while `srv` has Travis