Add customisable return types.

I've been playing with `rust-plugin`'s code in an attempt to add infallible plugins. I ended up just adding infallible variants of the regular `get` methods, as anything else requires the addition of higher kinded types or other stuff to Rust itself.

`cargo doc` is possibly the best way to get a feel for the changes as there are a billion lifetime parameters in the code itself. I hit an ICE when trying to infer lifetimes across closures passed as arguments to functions.

I think infallible plugins might be useful for Iron, as there are some cases where failure is impossible: `request.get_certain::<PathString>()`. Initially I thought they would also be useful for things like URL encoding, to avoid a double option type like `Option<UrlEncodedData(Option<HashMap>)>` but I now realise that the parsing should be done in the creation of the `UrlEncodedData`.

Perhaps infallible plugins aren't that useful for Iron (most data parsing can fail in some way?).

The other thing I've added is customisable return types, so that you can return any type from a plugin's get method.

```rust
// With custom return types
request.get::<UrlEncodedData>() // -> Option<HashMap<String, Vec<String>>

// Without (more unpacking required)
request.get::<UrlEncodedData>() // -> Option<UrlEncodedData(HashMap<String, Vec<String>>)>
```

Thoughts?
I think there's a problem here. This means that unless Plugin's want to re-compute R every time they are `get`ed they have to cache it themselves. I'm concerned that this represents a large increase in the amount of code necessary to implement an efficient plugin.

This is solvable by introducing an enhanced AnyMap which is keyed by types whose values can be a different type, as determined by a trait that the key has to implement. However, I think that this *also* introduces a rather large overhead into using the system.

I'm not sure what the correct approach is, if there is one.