Allow redactErrors to accept a function for custom error filtering

[ahce]

Currently, the redactErrors option supports a boolean or string value to control error redaction behavior, typically removing fields like stack and name.

It would be very useful to allow redactErrors to also accept a function, so users can define custom logic for how errors should be redacted before being streamed or serialized. This would provide more flexibility for different use cases, such as removing or preserving certain fields based on the error type or runtime context.

redactErrors: (error) => {
  return {
    name: error.name,
    message: 'custom messsage',
    stack: error.stack.replace(/some-regex/, 'some value'),
  };
}

Although the library provides a plugins option — an array of transformation functions like the following:

plugins: [
  (value) => {
    if (value instanceof Error) {
      return [
        'CustomError',
        value.name,
        value.message,
        value.stack,
      ];
    }
  },
]

— this approach does not work for error redaction, because the library internally converts errors to plain objects before the plugins are applied. As a result, the instanceof Error check always fails, making it impossible to target errors reliably through this mechanism.

Supporting functions in redactErrors would address this gap and make it possible to apply targeted logic to actual error instances before they're transformed.

[jacob-ebey]

I'd be open to making plugins run before errors are processed so you have a chance to implement encoding and decoding on a per-error type basis. I do not want to make the "final boundary" for sensitive information more configurable than yes or no "globally" at the moment. I'm even a bit sensitive about this as it enables a generic "encode all errors as is" plugin (similar to your example plugin above).