feat: Moved persistence-logic from `ChatHome` into `ChatHomeService`

- Aligned configuration and tests accordingly.
- Also fixed some camel-case typos.

refactor: Moved business-logic from `ChatRoomService` into `ChatRoom`

- Some essential business-logic -- the identification of mutated messages --
  was buried in `InMemoryChatRoomService`.
- This business-logic was moved into `ChatRoom`, becaus otherwise, it
  would have been necessary, to reproduce this logic in each and every
  new implementation of `ChatRoomService`, which would have been exhausting
  and errorprone.
- This allowed also cleaner code in `InMemoryChatRoomService`, that
  can focus on the persistence-logic.
- The implementation of `MessageMutationException` and the look of the
  accompanying problem-details hat to be refined accordingly.

fix: Asserted, that `ChatHome` acts, as expected, if asked for a `ChatRoom`

refactor: Streamlined the API of the services

- `ChatRoomService` and `ChatHomeService` both return only reactive types.
- The decission stems from the wish, to become reactive all the way from
  the client to the technical implementation of the backend-services.
- This faciliates the mapping of the results in `ChatBackendController`.
- The refactoring already simplified lots of code, where a `Flux` has
  to derived from the `Stream`, yielding a good feeling about the plan,
  that is pursued with this refactoring.
- The refactoring also lead to the decision that `UnknownChatroomException`
  realy is a business-logic-exception (that according refactoring was
  already performed in the previous commits, to ceap this commit clean).

refactor: `UnknownChatroomException` is a business-exception - Relocate

refactor: `UnknownChatroomException` is a business-exception - Move

fix: Fixed generated problem-details for mutated messages

feat: Implemented problem-details for `UnknownChatroomException`

- Implemented an `@ExceptionHandler` for `UnknownChatroomException`.
- Implemented `ChatBackendControllerTest`
  - Asserted, that the problem-details are generated as expected
  - Pinned down problems, that yield a refactoring and have to
    be resolved afterwards.

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