Methods needed to get owned headers out of requests and responses

The main case where this is currently painful is when trying to perform modifications while forwarding along an incoming-request as an outgoing-request, or incoming-response as an outgoing-response. The desired workflow is something like:

headers <- incoming.headers();
headers.delete("header-I-want-to-filter");
outgoing <- outgoing-request.new(headers);

Currently, this fails because headers is a child resource of incoming_request where the underlying headers are immutable, so methods like append and delete are not permitted. Invoking outgoing-request.new with this child resource is fine, with embedders able to clone the headers under the hood. But once it's in the outgoing resource it's once again only accessible via an immutable child resource.

As far as I can tell, the only way to modify headers in this proxying scenario is to explicitly clone the headers:

headers <- incoming.headers();
new_headers <- headers.clone();
new_headers.delete("header-I-want-to-filter");
outgoing <- outgoing-request.new(new_headers);

This isn't the end of the world, but it would be nice to avoid this clone and the implicit clone performed by constructing outgoing-request with a child resource by offering a means to get the headers back from these types as an owned resource. Perhaps we could, similar to Rust's http::Request::into_parts() method, augment the consume method to also return the headers (and other parts like method, authority, path, status code [for responses]) along with the body. Strawman signatures:

resource incoming-request {
  consume: func() -> result<(
    method,
    option<scheme>,
    option<string>, // authority
    option<string>, // path-with-query
    headers,
    incoming-body
  )>;
}

resource incoming-response {
  consume: func() -> result<(status-code, headers, incoming-body)>;
}

This will remain relevant even once 0.3.0 arrives with the unification of the incoming- and outgoing- types. If the headers can still only be accessed immutably from an existing value, proxy applications wishing to perform modifications will still have to get a mutable headers resource via some means, and absent other changes that'll mean an unnecessary clone.

Start with the issue's proxying workflow and strawman consume signatures, including the Rust http::Request::into_parts comparison. Determine which API shape provides owned headers and other request or response parts without the described redundant cloning; done means the interface decision is agreed and addresses that workflow.