Add more basic Twitch conditions, simplify some code and make it more consistent

[Destroy666x]

This PR:

• adds all basic Twitch EventSub conditions, except ones marked as beta, incompatible with websockets and one not too useful user one
• allows multiple token permissions per condition
• refactors code:

1. Simplifies generic Twitch event related functions for much less code. More advanced logic can go into new functions.
2. Separates basic events (which are always nice to have unchanged to just bump versions and quickly test in case of changes), advanced logic events and polling in a clearer and more consistent way.
3. Changes the condition numbering for more leeway. Basic events get +100 just in case, I can imagine 10 treshold being easily crossed with related advanced logic conditions at some point, this is more than enough, but better safe than sorry to keep things organized IMO. And polling starts at much higher number for the same reason.

I tested a bunch of conditions, I'll test some more today or tommorow live, the rest will need to be checked by people as I can't really access some features too conveniently.

Once this gets merged, I'll start working on a bunch more ID/regex matching conditions (e.g. specific points rewards or prediction/poll option winning)

[WarmUpTill]

Looks great!

Just found one minor issue:
The ConditionIsSupportedByToken() function seems to have returned true if either of the token options is set.
I adjusted to check if all options are set.

Also can you maybe also shorten the commit message of c772b40 or would you mind if I did so?

Thanks again for your contributions!

[Destroy666x]

Feel free to shorten the commit if needed (why just out of curiosity?)

[WarmUpTill]

Just want to adhere to the general git commit guidelines to avoid the commits being cut off with the "...":

I will adjust this once the PR is ready to be merged.

I had another look at the event handling:
I think the raid events (possibly more?) might need special treatment as here the broadcaster_user_id filed is replaced with to_broadcaster_user_id and from_broadcaster_user_id respectively.
So with the current implementation these conditions can never be true.

[Destroy666x]

Not sure what you mean, they already have special handling.

Ah, I see, the condition check also had broadcaster ID verification. I'll add a string param for that like in the other function once I come back home

[Destroy666x]

Fixed, quick scrolling didn't show any exceptions other than raid for this field.