Implement hooks via a trait and autoref specialization

[ahl]

So far we've allowed progenitor consumers to customize the generated code to calls to custom code before (pre-) and after (post-) the execution of all HTTP requests. This has been fine, but we've introduced now 4 variants with both overlap and significant limitation. In particular, when we wanted to include additional debugging output to our generated CLI, it turned out to be quite awkward and it wasn't clear how we could achieve our goals without also screwing up the SDK's interface.

This PR proposes a new trait that looks like this:

#[allow(async_fn_in_trait)]
pub trait ClientHooks<Inner = ()>
where
    Self: ClientInfo<Inner>,
{
    /// Implement to execute code prior to the execution of all requests.
    async fn pre<T>(&self, _request: &mut reqwest::Request) -> std::result::Result<(), Error<T>> {
        Ok(())
    }

    /// Implement to execute code after the execution of all requests.
    async fn post<T>(
        &self,
        _result: &reqwest::Result<reqwest::Response>,
    ) -> std::result::Result<(), Error<T>> {
        Ok(())
    }

    /// Implement to bracket the `execute` Future with your own code. Do not
    /// forget to `execute.await` at some point.
    async fn wrap(
        &self,
        execute: impl std::future::Future<Output = reqwest::Result<reqwest::Response>>,
    ) -> reqwest::Result<reqwest::Response> {
        execute.await
    }

    /// Implement to customize the execution of the given request.
    async fn exec(&self, request: reqwest::Request) -> reqwest::Result<reqwest::Response> {
        self.client().execute(request).await
    }
}

Generated code will implement this by default for &Client. Consumers who wish to customize things get to do so by simply impl ClientHooks for Client { .. } adjacent to the generated code. Today, hooks are specified in hard-to-debug quote! { } generated TokenStreams; with this change, we can effectively do the same thing--and more--in normal Rust code.

I'm not wed to aspects of the interface. For example, I thought that wrap would be useful, but now I'm not sure it is, so perhaps we remove it. I'm not sure of the appropriate return type for all of these methods--we may want to further modify the progenitor_client::Error type to adapt it to this new modality.

If this works out, I would definitely like to deprecate and/or remove the existing hooks as they're finicky, weird, poorly document, and hard to document.

You can see an example if this in action here: oxidecomputer/oxide.rs#1081. It does seem a bit more reasonable than the current mechanism.

[wfchandler]

Thanks, this looks very clean. Just to validate how robust this is, I tried implementing the trait in oxide.rs against &Client and got a very understandable error.

[wfchandler]

I like the elegance of this method, but it has a very large overlap with exec and doesn't grant access to the request, which I think most consumers would want.