Allow more versatile implementations of Polychat clients

[ThePixelbrain]

I was working on a Polychat client implementation for a custom Minecraft proxy.

While doing this I noticed some limitations in the Polychat client base I couldn't properly work around, so instead of hacking my way around them, I decided to make a PR!

These two limitations are addressed in this PR:

Config handling

Polychat requires a dedicated config file for each client and is incapable of getting config values passed during instantiation.

While this works fine in the scenario of a standalone Minecraft client, my client spawns multiple Polychat clients with similar configs. It is more reasonable for my usecase to maintain the configs on the implementation side and have them passed to the Polychat instance.

Which is what I did. I added an optional parameter YamlConfig config to the constructor of the PolychatClient class.

Logging

Polychat has System.out / System.err hard-coded for logging. While this is easy and doesn't introduce a dependency on a logging library such as Log4J, I want to have the possibility of configuring my own logger.

Therefore I added an Interface Logger that handles all logging methods. It's implemented by a DefaultLogger that uses System.out / System.err like before, but gives me the possibility of adding my own logger on my implementation.

Thread-safe sending queue

The message sending queue inside the Network Library wasn't thread-safe. If one thread received messages and another thread was sending messages, the queue could error because it used the non thread-safe ArrayDeque class. This PR replaces it with the ConcurrentLinkedDeque.

[HeatherComputer]

What made you strip the final from each of these?

[ThePixelbrain]

I removed them because I moved common initialization code to it's own method. I was kinda lost how to properly do this, the new approach is better.

[ThePixelbrain]

Made the message sending queue thread-safe and updated the original message accordingly.