CurrentlyResponseHeadersToAdd/Remove is settable on the RouteConfiguration. We'd like to add these fields to the VirtualHost and RouteAction as well, with the same precedence behavior as RequestHeadersToAdd.

@rshriram also notes that it would be nice to have both RequestHeadersToUpdate and ResponseHeadersToUpdate to be able to replace an existing header rather than adding a second value. I'm happy to let the schema gods determine the right naming/semantics.