feat: Introduced events that are send, if a shard is assigned/revoked

feat: Introduced events that are send, if a shard is assigned/revoked

* In order to redirect requests to the appropriate instances, each
  instance must know the mapping from  shard-IDs to instance-URIs.
** For the static `in-memory`-implementation `ShardedChatHomeService`,
   this is a static mapping, that can be configured and read on start-up.
** For the dynamic `KafkaChatHomeService`, this mapping has to be
   propageted to all instances each time the partition-assignment of the
   consumer-group changes.
* Changes for `ShardedChatHomeService`
** Introduced `ChatBackendProperties.shardOwners` (of type `URI[]`).
** Each instance reads the static mapping from shard-ID to instance-URI
   on start-up.
* Changes for `KafkaChatHomeService`
** Introduced `KafkaServicesProperties.instanceUri` (of type `URI`).
** Each instance reads its URI on start-up.
** `DataChannel` sends an event for each assigned/removed partition,
   when the partition-assignment of the consumer-group changes.
** These events propagete the changed mapping from partition-ID to
   instance-URI.
** `InfoChannel` receives these events and updates the dynamic mapping
   from partition-ID (aka:shard-ID) to instance-URI.
* The shards, that are owned by an instance, can be queried via `/shards`.