feat: Added a POST-mapping to force the storing of the data

refactor: Fixed return-types of the controller

- Renamed and moved `ChatroomInfo` to `ChatroomTo`
- Switched return-types from `Chatroom` to `ChatroomTo`

fix: `Chatroom`s must not share an instance of `PersistanceStrategy`

feat: The chats are stored as local json-files

feat: `ChatHome` returns an `Optional` for `getChatroom(UUID)`

feat: Introduced `ChatHome` that gives multiple `Chatroom`s a home

refactor: Moved configuration in a separate class and made it more explicit

refactor: Introduced `ChatroomFactory`

- `ChatBackendController` only has to know of the `ChatroomFactory`.
- `ChatBackendController` does not have to know the `PersistenceStrategy`.

refactor: Moved persistence-logic into a pluggable strategy

refactor: A `Message` now explicitly has a `MessageKey`

refactor: Streamlined API of `Chatroom` - all return-types are reactive

refactor: Refined field-names of `Message` and `MessageTo`

- Choosed longer and more descriptive field-names for the domain-class
  `Message`.
- Choosed short names for the TO-class `MessageTO`, which is serialized as
  JSON.

feat: `Chatroom.getMessages()` is fully paginated (takes first and last)

refactor: Refined packaging (renamed packages and classes)

refactor: Refined packaging (moved classes to new folders and files)

refactor: Renamed artifact to chat-backend

refactor: Reworked implementation of the problem-details [RFC-7807]

feat: Added problem-details [RFC-7807] for a message mutation error

feat: An `IllegalArgumentException` is thrown, if different messages are added for the same `MessageKey`

feat: Added logging for the `listen`-endpoint

fix: fixed the return-type of the `listen`-endpoint

feat: Implemented an endpoint to get the details of a chatroom

feat: implemented a listen-method for the chat-service based on a Flux

- Switched the return-type of `Chatroom.addMessage()` to `Mono<Message>`.
- Added an inner method, that "persists" the message and also returns
  `Mono<Message>`.
- `addMessage()` calls `persistMessage()`, peeks into the subscription and
  emits the `Message` to an internal `Sink.multy()` of the `Chatroom`.
- `Chatroom.listen()` creates a `Flux` from the internal Sink, so that
  multiple subscribers can listen on the sink and all retrieve the current
  messages in parallel.

feat: implemented a simplified chatroom-service

chore: Switched configuration from *.properties to YAML

refactor: Simplified the name of the application-class

chore: Fixed indentation of the `pom.xml`

chore: Removed the Maven-Wrapper

feat: Generated empty Spring Boot 3.0.0 App