I've found the validation errors returned are not that helpful. Consider the following examples:

1. Request with a missing path parameter: {"message":"must have a value"}
2. Request with an invalid enum value for a path parameter: {"message":""}
3. Request with a missing required attribute in the request body: {"message":"doesn't match the schema"}
4. Request with an invalid enum value for an attribute in the request body: {"message":"doesn't match the schema"}

This PR makes use of the Error attribute, which comes back as (overly verbose) multi-line text. However, the first line contains a useful amount of detail. The results (for the same scenarios) are as follows:

1. Request with a missing path parameter: {"message":"Parameter 'someEnumValue' in path has an error: must have a value: must have a value"}
2. Request with an invalid enum value for a path parameter: {"message":"Parameter 'someEnumValue' in path has an error: JSON value is not one of the allowed values"}
3. Request with a missing required attribute in the request body: {"message":"Request body has an error: doesn't match the schema: Property 'someProperty' is missing"}
4. Request with an invalid enum value for an attribute in the request body: {"message":"Request body has an error: doesn't match the schema: Error at \"/somePropery\": JSON value is not one of the allowed values"}

The full error text contains way too much information, including escaped JSON objects to describe the actual schema. I think this is too much info, so the first line seems like an easy way to get a good balance.