Better error messages when config.yaml is faulty

[Nicolai-vKuegelgen]

Is your feature request related to a problem? Please describe.
When the config.yaml has wrong, inconsistent or missing entries the snappy pipeline will fail.
However, in many instances the errors and messages given when failing like this make it very hard to figure out that a faulty config file is the issue in the first place and also don't give any hints regarding which sections of the config need fixing.
This also extendes to values machted between the config.yaml and the dataset specific samplesheets.

Describe the solution you'd like
If snappy can not find a certain entry in the config or finds it but with the wrong layout (= wrong parsed object type) an error or warning containg the faulty config entry should be given.
While some things could be done in individual functions it might be best to build a general solution that can look for structural / object type differences between den user given and default configs.

Describe alternatives you've considered
More config fields (and/or sub-fileds) could be marked as required.

Additional context
Some examples:

• The _build_ngs_library_to_kit function from the ngs_mapping workflow will run without errors even if it finds no mapping from sample to library kit (and returns and empty dict). However, subsequent functions/rules will not always work without this mapping.
• the _get_params_run function for the TargetCovReportStepPart (with alfred_qc) assumes that a 'default' library kit is defined, but nothing in snappy ever checks if this is even the case.
• most snappy workflows use the biomedsheet RefResolver class to read the config.yaml file. If the file is not properly formatted, the resulting errors do not indicating this problem or even mentioing the config.yaml at all.

[tedil]

I hope to alleviate these problems a bit with #496 which validates the configs via pydantic.
So far, I've based the pydantic models on the DEFAULT_CONFIG yaml strings of the workflows. I think these default configs aren't always complete or properly annotated (which fields are required etc), sometimes they're outdated etc. I.e. I can only guess what the config structure should be.

[Nicolai-vKuegelgen]

Sounds like a step in the right direction! And I agree the the current default config strings are not always helpful in solving these issues.