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.
Ok, gotcha. I think after removing the additional threading for creating a socket connection we can actually pull in the condition into the while check, effectively removing the current ```!Thread.currentThread().isInterrupted()``` check. So the code would look like this:

```java
  private void connectSocketAndDispatchEvents() {
    try {
      while (socketConnectionCouldBeEstablished()) {
        try {
          ObjectWriter objectWriter = createObjectWriterForSocket();
          addInfo(peerId + "connection established");
          dispatchEvents(objectWriter);
        } catch (IOException ex) {
          addInfo(peerId + "connection failed: " + ex);
        } finally {
          CloseUtil.closeQuietly(socket);
          socket = null;
          addInfo(peerId + "connection closed");
        }
      }
    } catch (InterruptedException ex) {
      assert true;    // ok... we'll exit now
    }
    addInfo("shutting down");
  }

  private boolean socketConnectionCouldBeEstablished() throws InterruptedException {
    return (socket = connector.call()) != null;
  }
```

About the potential problem of submitting a runnable to the thread-pool, when it can not except any further task: I think it is generally quite wonky that the whole logback framework shares one non-configurable (hardcoded to 32) thread pool. I think it makes much more sense that each use case manages its own thread pool and that there is no such thing as a globally shared pool. Each usage of the ```getContext().getExecutorService()``` may have different requirements towards task execution. E.g. the ```SMTPAppenderBase``` should probably have it's own configurable thread pool or the ```ReconfigureOnChangeFilter``` should probably have a fixed pool of size one which disregards currently running tasks whenever a new one is added and so on. I would suggest a couple of PRs which work towards removing the global thread pool and implement use case specific thread pools. My [PR](https://github.com/qos-ch/logback/pull/168/) will already remove two usages of the global thread pool. Btw. can we merge that thing as well?

In addition I think we should probably add some of the changes we do with the ```AbstractSocketAppender``` to its counter-part on the receiving side (```SocketReceiver/ReceiverBase```) in another PR.