Usability feature request

[crodwell]

Unless I'm mistaken, there is no easy way to dissect a RequestError into something useful for the user.

Take the following

requestError := err.(*openapi3filter.RequestError)

fmt.Println(requestError.Error())

/* output:
@body.name:
	Error at "/name":Field must be set to string or not be present
Schema:
  {
    "example": "doggie",
    "type": "string"
  }

Value:
  "number, integer"
*/

Further errors are just seperated via pipe and become unreadable quickly.

Would it make sense to define additional properties on the RequestError?

// RequestError is returned by ValidateRequest when request does not match OpenAPI spec
type RequestError struct {
	Input       *RequestValidationInput
	Parameter   *openapi3.Parameter
	RequestBody *openapi3.RequestBody
        ErrorItems []struct {
              Path  string                                                    // "/name"
              ValidationError string                                    //  "Field must be set to string or not be present"
        }
	Reason      string
	Err         error
}

[crodwell]

likely related to #465

[fenollp]

ErrorItems is a sensible addition. Feel free to open a PR with some tests (please)