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>`
Just a drive-by comment (got here from your Reddit post). 

Part of the Alloy approach is that work can be shared across multiple pieces of middleware. With this approach if multiple pieces of middleware need to parse the url-encoded parameters then the work is duplicated each time. You could write it to the alloy for downstream middleware to use but at that point the trait on Request is superfluous since that's exactly what UrlEncodedParser did anyway.

I agree that it's ugly to encourage people to use a pattern that assumes the existence of something in the Alloy since that introduces order-dependence in your middleware linkage without it being explicit. You have to know the underlying implementation of each piece of middleware to know what orders are valid.

It feels especially awkward to wrap this in Middleware given that it's nothing more than a pure function of the request data. It would be better if there were some kind of "provider" system where you can register a processor of some sort as a "provider" of a computed (potentially expensively) piece of data. The first middleware to request that computed data would trigger the computation by the provider and future requests would simply return the cached value. 

This way if you don't use the value in any middleware it's free (not computed) but if you do it's only computed once.