wasi-http: Fallible fields set and append

[elliottt]

This PR makes the fields.set and fields.append methods fallible, and introduces a new error type for describing the ways in which those operations can fail. Additionally it adds a notion of forbidden headers, which will always include the following:

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Proxy-Connection
• TE
• Transfer-Encoding
• Upgrade
• HTTP2-Settings

There's an embedder-defined hook for adding additional header name validation, but that underlying set of headers can't be altered.

Fixes #7270

[pchickey]

Looks great overall - rather than trap in the fields constructor, lets make the constructor create an empty set of fields, and have a static function that takes the list<tuple<...>> repr and returns result<fields, header-error>

[lukewagner]

@pchickey I think (but may be missing a case), that, with the eager-validation changes Trevor made most recently, there isn't a header-related error that can occur in the constructor?

Independently, the discussion made me think that perhaps (in a post-Preview-2 timeframe) we should relax the C-M constructor validation rules to allow constructor functions to return a result<containing-resource-type, T> (for any T). In languages with EH, this would map to the usual throwing-constructor pattern. Otherwise, bindings would produce their best approximation of a fallible constructor.

[pchickey]

The function set: func(name: field-key, value: list<field-value>) -> result<_, header-error>; allows rejecting input, but constructor(entries: list<tuple<field-key,field-value>>); would not allow that same input to be rejected with an error, so currently the implementation traps.

I agree we should allow constructors to throw in a post-p2 timeframe.

[lukewagner]

Ah, gotcha; I was thinking about the case of passing in the already-constructed headers.