(Java) Chat decorator should run in worker thread

The chat preview and the chat decorator system introduced in 22w19a allow dedicated servers to modify chat messages while allowing the user to sign. The system itself is great.

However, this has a oversight in the implementation where the chat decorator is executed in the server thread. Specifically, TextFilterer#filterTexts used by player-sent chat runs the result consumer in the server thread explicitly, and MessageCommand is executed by the server thread. This makes it hard to use web APIs in the chat decorator, since that causes huge performance issues/tick freeze and may potentially trigger the watchdog.

Use of external web API in chat decorator is essential for servers providing chat translation functionality, like the one I currently manage. To support such use cases, the chat decorator should run in a dedicated worker thread, and the code should use CompletableFuture for callbacks. This is already done with TextFilterer and is not hard to implement.

One thing to consider is that the decorate method currently takes a ServerPlayerEntity. If the developer uses the player (or the associated server, etc) and performs a write access, this can cause issues (such as a potential ConcurrentModificationException). However, since the network IO thread currently performs the same, this should not be a huge problem.

There may be times where the developer has to perform operations in the server thread. One way to make this easier is to change the return value to CompletableFuture<Text>.