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>`
That's a really cool idea. I think we could achieve your "provider" idea by having the mixin functions cache the value in the alloy. Something like:

```rust
fn get_expensive_value<'a>(&'a mut self) -> &'a ExpensiveValue {
    match self.alloy.find::<ExpensiveValue>() {
        Some(val) => val,
        None => { // compute value and insert it into the Alloy }
    }
}
```

Thanks for your comment!