[refactor] #1981, #4195: Refactor the event filters

[DCNick3]

Description

• rename the Filter trait to EventFilter
• "manually" implement all the event filters without macros
• remove all the filter combinators to provide a nicer and less nested API
• derive *EventSet types with a derive macro
  • a bitmask that represents a set of event types
  • serialized to json as an array of strings
• change the filter types naming scheme to be more logical:
  • AccountFilter -> AccountEventFilter (filters the event as a whole: by origin id and event type)
      - AccountEventFilter -> AccountEventSet (matches over a type of event)
• flatten the event filter hierarchy (account event is a kind of domain event, but account event filter is not)
• provide builder-like API for setting event filter fields

Linked issue

Closes #1981, #4195

Benefits

• more orthogonal API: only one way to filter for specific filter API (see [suggestion] Remove non-orthogonality from event filters #4195)
• simpler to navigate and edit due to using less macros (with comparable code size)

Checklist

• write code documentation about using the new API
• make ci pass

[DCNick3]

This new API doesn't allow to represent the filter "account created events within domain wonderland", which the previous system allowed.

This still can be implemented with the flattened approach by introducing typed id matchers. For example:

pub enum AccountIdMatcher {
  /// match any account id
  ByAny,
  /// match account id within a specific domain
  ByDomain(DomainId),
  /// match only a specific account id
  ByAccount(AccountId),
}

This functionality is somewhat related to the ValuePredicate::Identifiable predicate, though it treats ids as strings, which is unacceptable for the events IMO.

Anyways, I would prefer this to be implemented as a separate PR though

[Erigara]

Should we consider case for filtering multiple events?

Like someone wants to count number of accounts, it would be possible by filtering events registered or unregistered (and increment or decrement counter respectively).

Current workaround would be to create multiple event streams.

[DCNick3]

Should we consider case for filtering multiple events?

I did initially dismiss this idea (because the previous design did not allow this), but I think it's actually pretty doable by using a derive macro like enumset or bitmask.

I'll try implementing this