fix(validation)!: #266 validation.ValidationCommand no longer returns error if validation was run

[mike-winberry]

Description

Reworked the ValidationCommand and v.Validate() return values to make it more clear when a non validation error has been thrown by changing the above methods to handle errors and validation errors separately using the ValidationResponse and ValidationResult types.

• fix(validation)!: fix(validation): unclear distinction between "true" errors and "validationErrors" when using ValidationCommand #266 validation.ValidationCommand no longer returns an error when the validation has been successfully run (only returns error if it failed to initiate validation)
• fix(validator)!: validator.Validate() no longer returns the parsed basic output as an error and instead returns the jsonschema.ValidationError
• fix(cmd): validate cmd updated to handle ValidationCommand & validator.Validate changes
• feat(validation): ValidationResponse gained the JsonSchemaError *jsonschema.ValidationError field

Related Issue

#266

Type of change

• Bug fix (breaking)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[brandtkeller]

Resolves the identified issue. Currently prints both to stdout and the outputfile if specified - maybe that is intentional and otherwise doesn't block merge.

[mike-winberry]

Resolves the identified issue. Currently prints both to stdout and the outputfile if specified - maybe that is intentional and otherwise doesn't block merge.

intentional for now, not opposed to removing the log when the output file is set, I just always like my failures in the logs even if I am outputting.