fix mypy warnings

Bug: T328547

This MR is an example and RFC on the use of type checking to improve reliability of our codebase.

• introduces a new type-check CI job, that runs mypy on eventutiliites-python (tests are not yet covered).
• it applies fixed for errors triggered by the rules defined in setup.cfg (with no alternation)

Some considerations:

• in this exercise I addressed > 50 type nags, and discovered a bug in main that could break deployments (!27 (merged) ).
• pyflink does not export type annotations yet (to my knoweldge), and its imports will be ignored.
• py4j object are usually annotated with JavaObject.
• in this MR I possibly make an excessive use of Any. At times I found it hard to balance precision and verbosity. Maybe this is an aspect we could improve gradually with time.
• I adopted a config that - to my understanding - seems generally accepted as a good starting point by the Python community. However, mypy --strict will trigger more errors. Should we address those too?

Given the experimental nature of this work, the type-checking CI job is tagged as allowed to fail. We could test drive things for a while and decide to make it mandatory successful.

@otto @dcausse @tchin would love to pick you brain the usefulness of this. Do you find this level of annotation confusing? Will it introduce overhead? Or should go all in and run checks with mypy --strict ?