Make the error type configurable

[jorendorff]

So far, on the server side, we've required users to use a hard-coded error type, TwirpErrorResponse. The rationale was that we need an error type that the twirp machinery can convert into a syntactically valid Twirp response.

However:

1. Practically, as a user, I just want to use my project's normal error type. TwirpErrorResponse is a pain.
2. Users may want to set custom headers on the response. TwirpErrorResponse doesn't currently have any way to do that, and adding a mechanism would complicate the API.
3. Users may want to set response extensions on the responses, e.g. to can pass information to middleware that applies uniformly to all methods.

So this PR makes the error type configurable, requiring the user to implement a new IntoTwirpResponse trait to make sure users don't accidentally try to use error types that don't generate valid Twirp responses.

Copilot reviewed 8 out of 10 changed files in this pull request and generated no comments.

Files not reviewed (2)

• crates/twirp/src/client.rs: Evaluated as low risk
• crates/twirp/src/details.rs: Evaluated as low risk

Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more

[tclem]

I like this idea a lot. I'm a little unsure about the IntoTwirpResponse as it's really not doing what it says (and isn't there an axum trait for IntoResponse already?).

[tclem]

Nice!