Revise backend module interface

As discussed in our last meeting @daniel-eggert, I'd like to propose an alternative strategy to the implementation of the backend module. The current implementation (see ExampleMessageHandler.py) clearly provides too much freedom and the proposed interface with the __moduleInfo in Line 28 is difficult to read and write and not very pythonic.

With this approach, I am proposing an alternative strategy that is, in theory, based on a real python module with real python functions. You can see the implementation in the revised ExampleMessageHandler.py file of this PR. Instead of declaring the functions in __moduleInfo, we hide the logic in the demessaging.backend_base.BackendModule class.

1. This takes a module with the setup_from_module method (in the ExampleMessageHandler I took "__main__" assuming that you run the file via python ExampleMessageHandler.py),
2. it reads the functions from the __all__ attribute of this module (a common practice to declare public functions of a module in python),
3. for every function, it extracts the parameters plus documentation and type (this is not yet implemented, but I'd use docstring_parser for that
4. Listens to the de-messaging server via the start_listening function
5. if there is a request to the backend module via the messaging server, the call_function method is triggered that takes the correct BackendFunction
6. the BackendFunction is just a wrapper around the original function in the module (hello_world in ExampleMessageHandler.py) which does a validation of the input parameters prior to calling the real function.

With this approach, we are quite flexible. So you can also setup your backend module manually via the BackendModule.register_function method, and you can declare custom validators via the Parameter.type attribute.

What do you think about it? It would be straight-forward to create a __moduleInfo like json out of the BackendModule that could then be loaded by the pulsar (or any other frontend).