This method will allow a user of a ServerRunner to visit each of the
connected clients in order to do something with the client.

When the ConcurrentServerRunner is moved to core, it cannot reference
directly the Logger and LoggerContext objects.  Now the base class
delegates its logging to a subclass.

The javadoc references to SocketRunner will cause an unwanted important
when this interface is moved to core.

The ServerListener was converted to use a type parameter for the Client
subtype.  The Client interface was stripped down and the
remote-appender-specific methods were moved to a subinterface.  These
changes allowed the ConcurrentServerRunner and ServerSocketListener to
use a generic Client and to be reworked to move all of the
remote-appender-specific code to subclasses.  With these changes the
abstract base classes and interfaces can be moved to core to support
other server types.

In ConcurrentServerRunner, after the LoggingContext is resolved,
informational and error messages logged by the server should no longer
be written to the StatusManager associated with the underlying Context
passed to the runner during configuration.

The references replaced should have been referring to the interface,
not the concrete implementation.  This is just a left over from the
rename-concrete-class/extract-interface refactoring sequence not
handled automatically by the refactoring tool.

Notice during copy and paste testing of the examples.

This is for consistency with the JDK documentation and system properties.

These edits integrate the documentation for SSLSocketAppender with
SocketAppender, taking advantage of the similarities of configuration
and examples.

This should make it easier to diagnose SSL negotiation problems, in
particular.

The DEFAULT_PORT defined in SocketAppenderBase needed a public modifier
to allow it to be referenced in SocketServer.

If the appender configuration did not specify an SSL configuration, an
NPE would occur in method start when creating the SSLContext.  This NPE
would be trapped and logged, but subsequently the getSocketFactory
method would be called and would return null, potentially causing an NPE
further up the stack.  The fix is to ensure that the appender always has
a default SSL configuration, even if one is not specified in the Joran
configuration.

Unit tests for the SSLConfiguration already validate that an SSLContext
can be successfully created from an SSLConfiguration that is merely
instantiated, but has none of its properties configured.