Error handling in the `retry` processor

Currently, the retry processor scrubs the error of the origin message. This can be confusing for users. Maybe it would be better to not scrub it at all and make sure it's set back to its original value if one of the child processors clears it? Or maybe it's best to scrub it and set it back if the child processors don't set some other error? Or append to it the error coming from child processors? Not sure what's the best tradeoff...

Here's a sample config to experiment with:

input:
  generate:
    count: 1
    mapping: root = ""
  processors:
    - mapping: root = throw("kaboom")

  processors:
    - log:
        message: 'Before: ${! error() }'

    - retry:
        processors:
          - log:
              message: 'Inside: ${! error() }'

    - log:
        message: 'After: ${! error() }'

output:
  drop: {}

Start with internal/impl/pure/processor_retry.go around the cited error scrubbing and run the sample YAML configuration to observe the error before, inside, and after retry. Decide the intended error-preservation tradeoff with maintainers, then add regression coverage for the agreed behavior; done means the retry processor's error semantics are explicit and verified.