refactor: Added assertj-reactor for more readability

test: `LocalJsonFilesStorageStrategyIT` asserts, that the state is restored

fix: Implemented a test for `MessageTo` and fixed deserialization

test: Implemented a first IT for `LocalJsonFilesStorageStrategy`

- This first version of the test does not realy test the storing.
- It is only a proof-of-concept for the setup.

refactor: The `ChatRoom` determines the timestamp of a `Message`

refactore: Renamed `ChatroomService` to `ChatRoomService` -- Rename

refactore: Renamed `ChatroomService` to `ChatRoomService` -- Move

refactore: Renamed `ChatroomTo` to `ChatRoomTo` -- Rename

refactore: Renamed `Chatroom` to `ChatRoom` -- Rename

refactore: Renamed `ChatroomFactory` to `ChatHomeService` -- Rename

refactore: Renamed `ChatroomFactory` to `ChatHomeService` -- Move

refactore: Renamed `PersistenceStrategy` to `ChatroomService` -- Rename

refactore: Renamed `PersistenceStrategy` to `ChatroomService` -- Move

refactor: Only `LocalJsonFileStorageStrategy` restores `Chatroom`s

feat: Added an endpoint that list all messages of a chatroom

refactor: `LocalJsonFilesStorageStrategy` is now realy reactive

fix: The sink is recreated, if it gets canceled

- The sink is automatically cancelled, if the last consumer leaves.
- Turning auto-cancel of, is not an option, because this buffers new
  messages, until the buffer overflows, after which new messages are
  droped. Hence, if a new subscriber arrives, it would see some old
  messages and then, after a gap, current messages.
- Because of that, the sink is now automatically recreated, if the
  last subscriber leaves and triggers the automatically cancelation
  of the sink.
- The sink can be recreated without conflicts, because all methods,
  that may access the sink are synchronized.

feat: Server sends real Server-Sent-Events

feat: The size buffer for listeners to a chatroom is configurable

feat: Allowed the frontend as origin for CORS

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