Refactor multiple warning levels for same data validation filter

[dc-almeida]

Closes #439
Allows for a more compact writing of multiple warning level criteria (if warning level is ommitted, it defaults to error). Backwards compatible with more verbose syntax.
Stores the criteria for each level in descending order of severity (useful for upcoming PR that skips validation for lower warnings if a higher one failed).

[danielhuppmann]

The PR looks good to me, but I'm wondering how the "skipping" will work in the follow-up PR?

The current approach separates one validation-item with multiple criteria/warning-levels in separate items - how will the validation know that an alternative variant of the same item was already triggered?

I'm wondering if a better solution wouldn't be the other direction:

1. if the legacy-format is used, translate to validation-item to the new multiple-criteria-variant
2. extend the validation to go over the criteria within a validation-item until one is triggered and write to log

[dc-almeida]

Makes sense, and yes, makes the descending severity validation sequence easier to implement.

Question? in translating the legacy format to the new format, say the file contains multiple (separate) criteria for the same validation filter, but these may appear in any order in the file. It should be checked if the same type of item has been passed already and update it instead of creating a new one? That is, even if starting as separate legacy items, they end up aggregated in the object.

[danielhuppmann]

In translating the legacy format to the new format, say the file contains multiple (separate) criteria for the same validation filter, but these may appear in any order in the file.

Make it easy for us, implementation-wise:

• Don't worry about overlaps of criteria in the simple format. If there are multiple criteria items that check the same thing, there will be multiple warnings.
• Instead of actively sorting the multiple criteria in one validation item, just do a validation-step of the criteria that the sub-items must be given in descending order.

[danielhuppmann]

Maybe I'm confused about the order of validation-criteria? But it would be useful to have another variant of the test where only the low-warning-level criteria is triggered...

[dc-almeida]

Fixed the warning level skips; now, the DataFrame is updated to remove the already flagged rows for the same criteria (sharing different warning levels). The DataFrame is reset for new criteria. Had to use pandas to manipulate the IamDataFrame, since I couldn't find a clean and convenient method in pyam to match/drop rows.

[danielhuppmann]

Looks good to me overall, two minor suggestions inline

[phackstock]

Two small comments below. The correct use of ErrorCollector should be a quick fix. After that, you can go ahead with the merge without another review from my side. Thanks for the work @dc-almeida.

[phackstock]

Too much for this PR but as a future refactoring, I'd suggest to add an apply function (or something along those lines) to DataValidationCriteriaMultiple. This way this code would look something like this:

for item in self.criteria_items:
    item.apply(df)

and the rest is handled by DataValidationCriteriaMultiple.