Decide on nested wrapping of structured errors

Structured errors are currently a wrapped error and an optional error code. We have a builder, `NewStructuredError(error, string)` that is used to wrap the provided error along with the provided error code.

In https://github.com/elastic/package-spec/pull/690#discussion_r1467861976 a discussion was raised on whether we should wrap structured errors in structured errors. In some cases we are doing `NewStructuredError(errors.New(err.Error()), string)`, what loses infomation about `err`. We have to decide about what to do about this.

If we want to avoid wrapping structured errors, while keeping information about the wrapped errors, we can implement `NewStructuredError` as something like this:
```
// NewStructuredError creates a generic validation error by wrapping the given error. If the given error
// is already a StructuredError, the returned error wraps the error wrapped by the given error.
func NewStructuredError(err error, code string) *StructuredError {
if se, ok := err.(*StructuredError) {
result := *se
result.code = code
return &result
}
return &StructuredError{
err: err,
code: code,
}
}
```

And review the uses of `NewStructuredError` so we use it consistently.