Split hunter definition and registration

[iyehuda]

What would you like to be added

Separate the logic of new hunter definition and their registration to an event handler. The current implementation of subscribing new hunters is being made through handler - a global instance of EventQueue object. In the moment we define a hunter class, the handler singleton executes code that registers it into some data structures. This practice is bad since it is hard to test, it depends in a single global instance and it makes all hunters depend on it.

We can split it:

• Make the subscribe decorators standalone functions instead of handler methods. This way the decorators will just add subscription metadata to the subscribing hunter class, including subscribed event type and predicate
• Implement a register method in EventQueue that given a hunter class, registers it as it does today (same as subscribe_event)
• Make every hunter defined to be added into a global list of hunters (maybe a static property of the HunterBase class)
• In the main program: instantiate the handler and register all known hunters using the global list
• Supply every hunter a publish_event callback instead of referencing a global handler. Thus, inverting the dependency. Another idea is to make the execute method into a decorator and use yield to publish events that will be caught in the handler.
• Inject every hunter a config object instead of referencing a global one (see #341)

Why is this needed

• Resolve dependency issues - eliminate importance of import order
• Make practices better - eliminate side-effects import
• Improve code testability - easy to increase coverage

[iyehuda]

This is a major one so I'd like to get your opinion @lizrice @itaysk