WIP: Refactored Exception raising out of Gitlab::Config::Loader::Yaml

What does this MR do?

This MR is the beginning of a larger refactoring of the YamlProcessor. We would like to report as many errors as possible simultaneously from the YamlProcessor, but the current method of error detection relies heavily on Exceptions, limiting the completeness of the validation we would like to perform.

This one commit refactors away the Exceptions that have thus far been used in Config::Loader::Yaml to validate YAML configuration files located within the project. This does not change any Exception flow-control logic in YamlProcessor, but merely changes:

raise ValidationError, @ci_config.errors.first

to

raise ValidationError,
            @ci_config.errors.map { |e| e[:message] }.join(', ')

in light of the fact that we know @ci_config.errors is an enumerable.

I also decided to use a Hash to represent a single error, with the informative error-string found under the key message:. While it is currently the only key, I'd like to use the structure to allow for future additions to error message reporting. YamlProcessing has several parts each with it's own validation, and I'd like to give us as much room as possible to do richer, detailed error messaging.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry for user-facing changes, or community contribution. Check the link for other scenarios.
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Performance and testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers