Obfuscated schema validation messages make resolution cumbersome

Troubleshooting schema validation errors is cumbersome and should be more customer focused.

While troubleshooting a resource being provisioned the builder is left trying to figure out a few things. Based on the scrubbed messaging the user has to:
1. Determine what resource failed and its type
1. Run describe type on the type specified
1. Relate the error message, the properties of the resource, and the json schema definition to determine the correct pattern. When the definition names don't match property names this can become more difficult. When there are many layers of sub properties this can become more annoying. And when the value is a Ref/GetAtt to another resource its even more difficult to understand and translate what went wrong.

Example CloudFormation validation failure:
`Model validation failed (#/KmsKeyId: failed validation constraint for keyword [pattern])`

Example failure when calling the service itself (Lambda example):
`1 validation error detected: Value 'NotAArn' at 'kMSKeyArn' failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:[a-z0-9-.]+:.*)|() `

Obfuscated messaging was added by #40

I can understand not printing the value with secretsmanager dynamic references but we should at least be able to provide a path to the error and what is allowed (pattern, min/max length, etc.). This would eliminate so many of the above steps.

Also the layering of these error messages can make troubleshooting harder. This may be a documentation thing but took me a few times looking at the errors above to understand if the error was coming from CloudFormation or form the service itself. In this scenario the error coming from the service was more detailed and allowed me to resolve the issue quicker than the CloudFormation error but I'm not sure that is always the case.

No files, tests, or entry points are identified. Start by tracing the obfuscated validation messaging added by #40 and compare the CloudFormation and service-level examples. Done means validation errors provide an actionable error path and allowed constraints without exposing secret values, while making the message layers clear.

Written by the indexing model from the issue text.