Remove users of pkg/errors.WithStack, pkg/errors.Cause

[mtrmac]

Motivated by containers/podman#14784 removing pkg/errors.

This does not remove all of it: We still use pkg/errors.Wrap* to provide an unchanged interface to callers that rely on pkg/errors.Cause.

• Stop attaching stack traces to errors, other than as implied by pkg/errors.Wrap*. I.e. use errors.New instead of pkg/errors.New, fmt.Errorf instead of errors.Errorf, remove a few explicit pkg/errors.WithStack. Those were never promised (OTOH Podman does have at least one fmt(…%+v…, err), so this might break something).
  • We could drop stack traces also from errors.Wrap* by replacing that with errors.WithMessage*, but that’s a mouthful, and we want to eventually eliminate those fully…
• Eliminate almost all uses of pkg/errors.Cause; use errors.{As,Is}. Note that this could, in principle, change behavior, and I didn’t examine the call stack in detail. c/storage is probably the most risky in this respect — OTOH I have a hard time thinking of a specific scenario where this would break, and we need c/image to update this before c/storage can eliminate pkg/errors.Wrap*. We retain one pkg/errors.Cause in tests, at least for now.
• Consistently import errors as errors, and pkg/errors as perrors, so that we can refer to both in the same file.
• Fix some random typos in error strings.

See individual commit messages for details.

I’d be happy to split this further as suggested, or drop/defer this now and return to that effort some time later, to coordinate with other work (notably because this would almost certainly require a rebase of any other outstanding work — and one more rebase after we eliminate pkg/errors.Wrap*).

[mtrmac]

Note to self: There’s probably a more reliable argument as to whether replacing errors.Cause is safe (if we know whether the type we are looking for implements Cause() or Unwrap()).

[vrothberg]

LGTM
Nice improvements!

@rhatdan PTAL

[rhatdan]

LGTM