Polymorphic registration of subsystem `IntegrationEvent` in subsystem's `SerializersModule`

[Whathecode]

Recently, the subsystem-specific SerializersModules were removed since all extendable types were moved to the common subsystem.

However, @ltj ran into an issue when trying to implement the event bus. An event bus needs to handle subscribed IntegrationEvents polymorphically. To do so it needs a polymorphic serializer. Since IntegrationEvents are sealed classes, these are not registered as polymorphic types.

Should we/can we solve this in core? Currently, Lars knows which serializer (when deserializing) to use based on the source of the event (the application service). This works. But, can this be made cleaner?

[Whathecode]

Any solution I can think of would not be a breaking change, but a feature in later versions (minor version bump). I think it makes sense to keep this on the backlog, but removing this from the 1.0.0 milestone.

Essentially, this is an infrastructure concern. Core could expose a serial module with all IntegrationEvent's registered, but this only really makes sense when CARP is deployed as a monolith. Alternatively, we could reintroduce a distinct SerializersModule per module which registers all dependent concrete IntegrationEvents (those which the application services subscribe to). This would make sense when CARP is deployed as microservices and a different event bus subscription is set up per service.

The main problem currently is that whoever needs to implement infrastructure needs to know about the concrete IntegrationEvent types subscribed to by core in the application service hosts. Maybe down the line we can come up with a different way of exposing this statically in the current codebase than reintroducing SerializersModule per subsystem.