Support mapping the contents in sync_response store

Currently, sync_response adds messages to an internal store and passes them back to the input. In the case of http_server input, this results in a multipart response. This isn't desirable in my use case:

input:
  http_server:
    path: /what-the-blob
    allowed_verbs:
      - POST
    sync_response:
      status: '${! meta("http_status_code").or(500) }'

pipeline:
  processors:
    # usually some stuff here
    
    - mapping: |
        #!blobl
        meta http_status_code = @http_status_code.or(500)
        root = if errored() { {"error": error()} } else { {"result": this} }

    - sync_response: {} # capture the desired response here

output:
  fallback:
    - gcp_pubsub:
        project: foo-project
        topic: foo-topic
    # if we get to this point then there are 2 messages
    # in the store and we'll get a multipart response
    - sync_response: {}
      processors:
        - mapping: |
            #!blobl
            meta http_status_code = 500
            root = {"error": @fallback_error}

In this example, if we fail to publish a message then two messages are added to the sync response buffer and the response seems to be a 200. I'm trying to think of ways to solve this. One idea I wanted to bounce: Should sync_response take a mapping that gives the current state of the store and let you return the next state? The default config that matches today's behaviour:

sync_response:
  mapping: |
     root = this.store.concat([this.message])

Start at the sync_response input and output entry points and trace how messages are added to and returned from the internal store. Review the proposed mapping interface and its default mapping, then define behavior for selecting the next store state. Done means the mapping can control the captured response while preserving today's behavior by default, including the HTTP response case.