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.
I agree with merging the socket-managing and socket-creating threads as I don't think they need to be separate. The result of `ExecutorService#submit(<socket-managing thread>)` in `AbstractSocketAppender#start()` would need to be checked (this is another bug that we never handled), and I'm not yet sure how to recover from a failure there. We might have to queue a retry or (less preferably) bail with an error message to increase the thread-pool size.

Also, good point on the persisting the connection instead of creating a new one per iteration. The performance of the `SocketAppender` would likely be improved by reusing the same connection. It would also minimize port contention in between our connections/log-events.

On the other issue, I actually was not suggesting the removal of the null-check. When I said "continue instead of break", I was suggesting we loop back to the beginning with the `continue` keyword instead of `break`ing out of the loop.