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>`
Yes. Since Request now stores Alloy mixins can store data so it persists throughout a request - in fact, mixins should ensure to do this for any data which probably won't change or wouldn't change under normal circumstances. Splitting this into its own category of middleware may be interesting.

This pattern (which @michaelsproul showed an example of in his comment) seems pretty common. I wonder if there is room to sort of split middleware up into categories. I was thinking that this might be doable with a simple wrapper middleware that accepts a fn that produces a value from a Request and a Response, but it's trickier than that because you also need to provide a mixin for Request or Response that is the approved way to get at the value.

This is a tricky issue, but I think there is an elegant solution to be found. Maybe this means making the Middleware system a bit more complicated, or introducing a sort-of Plugin system - I'm not sure yet.