Make errors.Formattable more useful, fix a redact bug This patch ensures that the result value from errors.Formattable also implements error, so that detailed error output is properly produced if formatted via %+v. It also bumps the redact dependency to fix a bug.

Fix a silly bug 

Make `WithSafeDetails` more useful Prior to this patch, `WithSafeDetails` was capturing safe strings but they were not shown in the output of `%+v`. This choice was made at the time where `WithSafeDetails` was the only way for `errors.New` to capture safe strings for reporting. At that time, displaying the safe strings in the `%+v` output would *duplicate* error messages: once from the `Error()` output, and one from the safe details. Since v1.7, `errors.New` and related functions do not use `WithSafeDetails` any more. The risk for data duplication is thus removed. So this patch evolves the wrapper produced by `WithSafeDetails` to also report its safe strings during `%+v` renderings. Additionally, the logic for `WithSafeDetails` previously duplicated information from the arguments: the text would be rendered once in full in the first detail string, then each argument would be detailed further (with type information and all) in additional strings. For example: ``` WithSafeDetails("hello ", redact.Safe("world")) (1) 2 safe details enclosed | hello world | -- arg 1 (string): world ``` (See how "world" is duplicated) In practice, this amount of detailing has not proven useful, and it is in fact detrimental to the readability of error strings. So this patch removes it. The new output for the example above is: ``` (1) hello world ```

Clarify PII safety in README. 

safedetails: More improvements to error redaction This makes multi-line error details indented.

safedetails: More improvements to error redaction This makes multi-line error details indented.

Make `New()` and `Wrap()` consider their string as PII-free **THIS IS A BREAKING CHANGE.** The `errors.New()`, `errors.NewWithDepth()`, `errors.Wrap()` and `errors.WrapWithDepth()` now consider their string argument as PII-free, and the string is now also included in Sentry reports. This is a breaking change: in previous versions, only the format argument to `errors.Newf`, `errors.Wrapf` etc was considered to be PII-free. This also means that **care must be taken when using this `errors` library as drop-in replacement for other errors libraries**: callers that use `New()` and `Wrap()` directly must be audited to ensure that they indeed pass strings that are safe for reporting to Sentry. This can be enforced e.g. via linters that assert that the argument is a literal (constant) string. This is the approach taken e.g. in CockroachDB.

Merge pull request cockroachdb#43 from cockroachdb/20800812-report report,redact: incrementally improve the ergonomics of reports

Update go.mod. 

Update go.mod.