feat: Remove usage of Guava

[ctasada]

The Guava library is really convenient, but over time, most of its features became part
of the vanilla Java.

This PR removes the usage of Guava, replacing it by Java equivalents.

[tvahrst]

Concerning MessageHelperTest: there is no garantuee, which of message2,message3 won the deduplication, so I suggest this assertion:

        Map<String, List<Message>> oneOfMap = (Map<String, List<Message>>) asObject;
        assertThat(oneOfMap).hasSize(1);
        List<Message> deduplicatedMessageList = oneOfMap.get("oneOf");
        // we do not have any guarantee wether message2 or message3 won the deduplication.
        assertThat(deduplicatedMessageList)
                .hasSize(2)
                .contains(message1)
                .containsAnyOf(message2, message3);

BTW: MessageHelper#toMessageObjectOrComposition expects a Set of Messages, but Message does not implement equals/hashcode. So the Set Sematics are not used and the Set is defacto a List of Messages. Internally, duplicates are removed via a special stream using a messageSupplier which in turn uses a TreeSet which in turn is configured with a Comparator which compares the name of the message.
If the message name was the 'unique' id of a message, this could be easier achieved by simply implementing equals/hashcode in the Message class.

[tvahrst]

Concerning Async*AnnotationScannerTest: The order of entries in map is not garantueed, so it should be:

 assertThat(actualChannels)
                .containsExactlyInAnyOrderEntriesOf(
                        Map.of(
                                "test-channel-1", expectedChannel1,
                                "test-channel-2", expectedChannel2));

instead of containsExactlyEntriesOf

[ctasada]

@tvahrst Thanks for the suggestions. They work like a charm 😄

Regarding the equals comment. Message implements Lombok's @Data annotation, which adds the @EqualsAndHashCode. So the generated Message class is implementing equals/hashcode.

Is the MessageHelper the one that uses a Message::getName comparator to remove the Message duplications, based on the name.

I would say that this is the point that should be discussed. Are 2 Messages with same name, but different description equals? If that's the case, then we could probably modify the equals implementation to ignore the description, providing a much more consistent (and simple) behaviour across the library.

@timonback @tvahrst what do you think?

[timonback]

@ctasada That is a good question, whether a message is equal or not.

At this point, Springwolf only uses the name of the message - as the name is used in the ui through the schema name. As soon as we have methods which get detected multiple times (i.e. KafkaListener and AsyncSubscriber annotation together), we find the same message payload class twice, but only want to show it once - first one wins.
(There are other use-cases, where we do not want to rely only on the class name. For example, when we have the class name in different packages -> limitation)

I am fine to continue to use only the name for checking the equality of a message.

When looking at the spec, there is the option to use Message#messageId for a unique name.
We can improve further (in the future/other PR) - as we might need to adapt springwolf-ui as well.

Feel free to look into it.

[ctasada]

@timonback I think this PR is ready for merge. I don't think this PR introduces any behavioral change.

The suggested change regarding Message comparison I think should be attacked in it's own PR. I can take a look later

[timonback]

Thank you very much to go through all these occurrences and replacing them with the latest Java features in order to remove the guava dependency!