LOGBACK-977 - AbstractSocketAppender loses event for every socket connection break

This pull request aims to fix losing events during a socket connection problem. Previously whenever the socket connections drops at least one event is silently being dropped. 

I order to verify that an event actually has been transmitted before removing it from the queue I switched the logic for queue consumption from "take" to "peek/remove". 

This required to abandon the usage of a ```SynchronousQueue```, because it does not support the peek method. However, having an ```ArrayBlockingQueue``` with the size of one should cover the use-case. For compatibility reasons I treat every queue size smaller than one as one inside the ```AbstractSocketAppender.newBlockingQueue``` method. The ```AbstractSocketAppender.start``` method will now output a deprecation warning when it finds a queue size of zero.

I would like to "clean-up" and extend the existing ```AbstractSocketAppenderTest``` and make the ```AbstractSocketAppender``` a little bit more testable by pulling out the aspects of queue creation and output stream creation to provider classes. Please tell me if that is fine with you guys, so I can go ahead and do the change.

Btw. when looking through the documentation in the website module I found this sentence:

 _In particular, in the extreme case where the network link to the server is down, the client will be eventually blocked._ 

Looking at the most recent version of the ```AbstractSocketAppender``` this sentence seems false. Should I fix it, while I am at it?

this description is outdate, please read the comments below.
@tony19 I have been thinking about your comments. I think we can remove the connectorTask completely as a member. We are already running on a thread (different than the main thread) so we basically spawn of a thread from a thread (```activateConnector()```) just to join (```waitForConnectorToReturnSocket()```) them both again one line later. Additionally I think we should keep the SocketConnector as a member instead of re-creating it inside the loop every time we lose the connection.

About the socket it-self, I do not think we can remove the null-check. Assuming the thread is being interrupted, which would now be the same thread for the while-loop and the socket-creation, it might happen that we are just waiting for a socket connection while the interruption happens. This could cause the SocketConnector (```DefaultSocketConnector``` to be precise) to return null which would cause the loop to fail with a NPE before it reaches the while condition which checks for the interrupted flag.