transform-middleware for webrequests

This is an idea from the slackchat:

```
me: btw. just curious, have you considered adding middleware for jasonette web-requests?
My case above is obviously not a good example for that.
But i could imagine transforming incoming json into something else.
Let's say you want to search thru all github AND gitlab repositories using 2 api-calls, which both have a slightly different array of results.
It would simply things a lot if the jasonette-app could use one internal json-format.
This would be possible, if you could just write 2 middleware functions (gitlab + github) which transforms the incoming result into the internal json-format..and render it

ethan: that's an interesting idea. i guess the challenge is how to actually implement it
if you have good ideas, feel free to share more details on github as an issue
```

A simple middleware pattern could allow *all jasonette-clients* (web/ios/android) to aggregate or transform incoming data and/or outgoing data.

## Usecases

* to aggregate multiple api's into a single internal format
* to patch incoming data (e.g. missing json-property due to bug or version-change of api)
* to patch outgoing data (e.g. add specific required headers like RESTFUL pagination)

## Example middleware in jasonette json

This is just thinking out loud, and can probably be improved a LOT

```
{
"$jason:{
head:{
webrequest:{
"POST":[
"url":".*gitlab\.com",
"transform":{
"headers":{
"X-API-TOKEN":"fe34fe3fe43",
"X-Total-Count": "{{mysettings.max_items}}"
},
"payload":{
"page":"{{mysettings.page}}",
},
"result":{
error: "{{this.gitlab_repositories.length ? true : false}}",
repos: "{{this.gitlab_repositories}}"
}
}
]
}
}
}
}
```

## Basic idea

```
whenever jasonette does a webrequest
╰￫ check if the url + method matches with the `webrequest` section in `head`
╰￫ call selecttransform on the payload+header
╰￫ forward the result of `process(request, doActualRequest )
╰￫ call selecttransform on the `result`
╰￫ forward the result of `process(result, renderTemplate )`
```

## Considerations

Im curious about your feedback, and I'm definately not sure whether we **should** pursue this path.

#### reasons to not support it
Sometimes deciding **not** to write a feature can be also be a huge blessing.
All the logic above could also be written as a proxy-api server-implementation, instead of a client implementation..

#### reasons to support it
These days all focus is rather on the frontend, that's where the money is.
Therefore flexible transformation-features of i/o can be very attractive, all power to the frontend-dev.
CRUD Server-development seems to be a necessary evil these days (imho), preferrably abstracted away by phrases like 'serverless','apaas' etc.

No source files, tests, or entry points are named. Start by reviewing the existing webrequest handling and the proposed request/result transformation flow, then clarify the middleware design and client scope with maintainers. Done should mean an agreed implementation plan covering aggregation, incoming and outgoing transformations, and behavior across web, iOS, and Android.

Written by the indexing model from the issue text.