Allow listening to ProcessDataMonitor events inside of other MORYX components.

[andreniggemann]

Is your feature request related to a problem? Please describe.

Events that are collected by the process data monitor can not be processed by other components outside of ProcessDataListeners.
In general this leads to duplicated code because existing driver implementations for the communication with external systems can't easily be reused for listeners. Additionally I can't share a connection when a listener as well as another component requires a connection to the same network resource.

Describe the solution you'd like
I would like to add an event to the ProcessDataMonitor that can inform other components about measurements received by the PDM.
This way I could forward this event to interested resources. (Inverse flow of the Moryx.ProcessData.Adapter.ResourceManagement) and other modules.

Describe alternatives you've considered
Another option might be to add an optional dependency to the ResourceManagement in the PDM. This would allow Listeners to be implemented on the back of Resources/Drivers.

Additional context
For a concrete problem that has me thinking about this:
I'm currently considering is adding Apache Sparkplug support to MORYX to send data about the machines state to a centralized monitoring system.
We would like to collect ProcessData-Events over the same MQTT Broker. With the current implementation we would run into a few issues.
One small thing is that we would need to configure the mqtt connection twice. The slightly bigger issue is that some MQTT Brokers don't allow two MQTT Connections with the same set of credentials at the same time.
This means that we would need to manage two identities per machine.

[Toxantron]

Providing an event about measurements on ProcessData is alright, but I want to add I am not in favour of using drivers to communicate to IT systems or clouds. It breaks the idea of the 3 layer MORYX architecture and overlaps IT and OT systems.

But I do see the need to use MQTT for adapters as well as drivers.

Also a heads up: We want to get rid of the current adapter structure and implement a generic event listener structure to fetch data from any module.