Split state into a separate parameter

[yoshuawuyts]

This PR changes the relationship between request and state. Instead of embedding request and state into the same type, it makes them two separate arguments. So req: Request<State> becomes req: Request, state: State. The idea behind this is that for smaller applications that are only parameterized by a single type calling that type "state" feel somewhat indirect.

Take for example this MongoDB example:

async fn index(req: Request<Database>) -> tide::Result {
    let coll = req.state().collection("fun_numbers"); // `req.state()` == `Database` is a relationship that is non-obvious
    let res = coll.insert_one(doc! { "x": 1 }, None).await?;
    let body = format!("the inserted id was: {:?}", res);
    Ok(Response::builder(200).body(body).into())
}

req.state() feels like an odd indirection to get to the parameterized type. Instead if the type was a direct input to the function it'd be easier to name and use:

async fn index(req: Request, db: Database) -> tide::Result {
    let coll = db.collection("fun_numbers"); // It's clear we're calling a method on the database here
    let res = coll.insert_one(doc! { "x": 1 }, None).await?;
    let body = format!("the inserted id was: {:?}", res);
    Ok(Response::builder(200).body(body).into())
}

This also makes it easier to convert from http_types::Request to tide::Request since the State param does not need to be populated. I don't think this functionally changes much about Tide; except that in some cases it'll just feel that little bit smoother.

[yoshuawuyts]

One question raised on Discord by @jbr is whether we may instead want to merge / combine "global state" and "local state" into a single type. This could take the shape of a typemap that's passed along with both request and response.

Also related are #645 and #643.

[mdtusz]

What's the state (heh) of this PR? Having the state as a separate arg does seem to be a better interface to me so no opposition here, but it would be nice to either close or land this. The local/global states would be excellent too (I assume you meant request-local state).

[joshtriplett]

This and #895 seem mutually exclusive, and #895 seems like a cleaner approach. What do you think, @yoshuawuyts?