Refactor Compound Triggers / Filters

[stiesssh]

Follow up issue for #30.

As described in #30, the current mindset regarding compound filter is like this:

Mindset: a CompoundFilter is also a FilterChain i.e when using compound triggers, we get tiny filter chains inside our topmost filterchain, which consist of targetgroup checker, trigger checker, constraint checker etc.
Thus, we must/can rely on the filter operations next and disregard to realize the OR and AND filters.

In #30, we attempted to implement an Triggerchecker filter for the compound OR Trigger, while sticking to the current design. In the end, the presented solution works, but violated the (implicit) contracts of the FilterChain class.

Thus, we want to refactor the Triggerchecker for the compound triggers, such that they do not extend the FilterChain class.

Goal

1. come up with a reasonable design
2. implement the solution

Pitfalls resp. things to keep in mind.

• Compound Triggers can be nested, i.e. we can have a compound OR-Trigger nested into an AND-Trigger, nested into an OR-Trigger and so on.
• Currently, logical operators AND, OR and XOR are supported by SPD.