Consider Mixins?

I had a go at implementing the URL encoded parser as a mixin. I must say I quite like the result. It's safer (and cleaner) than using Middleware, because you don't have to worry about the option type returned by `Alloy::find`. This in turn means you don't have to use `unwrap()`, which is probably what most people would do.

I even reckon we could take this idea further, and have the majority of the current Middleware implemented as mixins. If we did this, we could move to a system where a "handler function" is privileged over middleware, and has a type signature like:

```rust
fn handler(req: &mut Request) -> Response;
```

You could call the handler at the end of the middleware stack, before going back up? This would necessitate a change to the `Middleware::enter` method:

```rust
fn enter(&mut Request) -> Status;
```

Logging, response timing, and other things well suited to being middleware could remain middleware, whilst all request parsing and response creation could be handled by mixin functions called from the handler function. Things like `Request::parse_json_body()`, `Response::json_from_str()`, etc. This also neatly solves the problem of what to serve as the default response -- the handler function *must* return something!

It's currently 12:30am where I am, so this may seem crazy/stupid by light of day. Let me know what you think!

`</braindump>`
I was thinking of something along those lines. I'm unsure where cache/map would actually be stored but I think something along these lines would be quite interesting. You could of course also do:

```rust
pub trait Plugin<Produced> {
  fn compute(&mut Request, &mut Response) -> Produced;
}
```

Then somehow create an Alloy where objects are keyed by a type but can be of any value. I'm not super sure how that can be done safely without resorting to just returning a Box<Empty>.