Handling/forwarding `error-context`s that can be generated during a `body.finish`

During some implementation for error-contexts in futures in the wasip3-prototyping repo, we found that there was an issue with wasi:http/types#body.finish, as it implicitly does a future.read which can return a value or an error-context in the case of an error.

There are a few ways that we can solve this (thanks to @rvolosatovs and @dicej for suggestions), but a short incomplete list follows:

1. Change the finish method signature from result<option<trailers>, error-code> to result<option<result<trailers, error-context>>,error-code>
2. Absorb the error and convert it into an existing error-code (likely internal-error)
3. Create a new error-code variant that stores an error-context

(1) is a reasonable approach but pollutes the type and possibly unreasonably forces caller to handle the error-context directly.

(2) causes some loss of context in an almost certain future version of error-context -- the best example is of an error context that can hold multiple traces (similar to an anyhow::Error), if we were to boil down the error context into only a string (given the current variants for error-code)

(3) Seems like an ideal option as a variation of (2) -- an additional error variant like internal-error-context(error-context) which would

There are of course other ways to handle this, so I'd like to open this up to discussion before submitting a PR to make the change (going for WebAssembly/wasi-http#3)

Start with wasi:http/types.wit at the body.finish definition around line 265, then read the Canonical ABI future.read behavior linked in the issue. Compare how body.finish can forward an error-context and review the proposed alternatives before checking WebAssembly/wasi-http#3. Done means an agreed handling approach is documented and ready for a PR.