Is your feature request related to a problem? Please describe.

When I'm wrapping an error, I often have some interesting data that I'd like to include in the wrapping that can be programmatically accessed later. For example: I have an error produced in the process of doing some I/O, and I want to return an error that both wraps that error and also includes some information about the larger operation I was trying to perform, so that the caller can either respond in some way it deems appropriate, or log some structured data that can be easily retrieved later, or so on. I want stack traces to continue to be generated as if I were just wrapping with a string.

Describe the solution you'd like

I'm thinking of adding a Wraps (s for structured) that takes an error. The provided error will be used by the wrapError to:

• generate Error() output.
• proxy Is(), As() (if I return eris.Wraps(err, &MyError{...}), then that returned error should yield true for `eris.As(err, &MyError{}). similarly).

Unwrap() will remain unchanged so that traversing the causal chain remains functional.

Describe alternatives you've considered

• Wrap with a string containing some structured data.
  • this makes the default action (sending to an error log) unwieldy and requires callers to parse it, and complicates distribution of structural knowledge.
• Do the wrapping myself
  • breaks stack trace reporting
• Embed some eris-provided type that allows eris to maintain its data within my error
  • This is much more intrusive to the user.

**Additional context

None, I think. I started prototyping this out but am as yet unsure if my current approach will prove satisfactory, but I thought to leave a note here early to gather any feedback.