gateway: support extension hooks

[willscott]

Per ipfs/specs#431 - there is a desire for clients to be able to signal support for additional semantics in their requests to the gateway handler.
ipfs/specs#412 introduced a spec location for signalling of additional parameters.

The ask of the boxo library is how to support usage of the gateway handler with registered support for additional semantics / callback hooks to allow for transformation / changed behavior based upon signalled requests for such.

Currently, the best approach would seem to be for the server to wrap the boxo handler with middleware, which would have to re-parse inbound requests to identify extension semantics, and filter/transform the response as a byte stream. That approach seems like it may lead to unwanted amounts of code reuse. On the flip side, the choice of appropriate hooks to allow server code to plug into does not seem immediately obvious either.

[Jorropo]

favor composition over inheritance

• Someone once said.

And thus wrap the handler.
We could decouple the car serialization from the rest of the gateway implementation.
So I would do something along the lines of:

// Pseudo code

// BlockStreamResponseWriter is a copy of [http.ResponseWriter] except write takes in a blocks argument instead of bytes.
// This allows consumers to modify the car without having to reparse it.
type BlockStreamResponseWriter interface{
	Header() http.Header
	Write(blocks.Block) error
	WriteHeader(statusCode int, carRoots []cid.Cid) // I'm unsure about carRoots
}

// ServeCar only supports the responses formats which outputs cars and should only be used for code that wants to do specific things with the car.
func (*Gateway) ServeCar(w BlockStreamResponseWriter, req *http.Request) error