Still needs lots of proofreading...

The subclass may need a reference to executor to pass to objects that
will need it later when the receiver is running.

This will make it easier to refactor SocketServer so that it extends
ReceiverBase.

The object that is composed with a ServerRunner already implements
LifeCycle.  Having a start method complicates the use of the runner
without adding any real value.

Also fixed up the taxonomy -- what was a SocketRemote is now a receiver
component that connects to a remote appender peer.

This will eliminate the need to add a nested component rule for each new
SSL component.

ReceiverAction can instantiate a component that is a subtype of
ReceiverBase.  SocketRemote and SocketServer will be refactored to
extend the ReceiverBase type.

The existing SocketRemote and SocketServer classes will be refactored to
descend from this base class.

In preparation for introducing the concept of a "receiver" component
(which can be either a component that listens passively for incoming
connections from remote peers or one that actively connects to a remote
peer), this commit fixes up the taxonomy in the ServerSocketAppenderBase
implementation.  Now a ServerSocketAppender will have zero or more
connected remote receiver clients.

The MockAppender now uses a BlockingQueue to hold appended events
until the test subject can pick them up using either awaitAppend or
getLastEvent.

Just a first draft.  Please edit and/or pare down as appropriate.

components

This ensures that no queuing occurs when the number of threads is less
than or equal to the maximumPoolSize.  Also added constants for all of
the default values, and changed the defaults for maximumPoolSize and
keepAliveTime.

The ExecutorService in the context has a very limited thread pool
configuration, and using it as is breaks the existing socket-based
components that rely on concurrent execution.

This test was broken when the InstrumentedServerSocketBase was modified
to allow assertion testing for the context's executor service.

n ServerSocket.stop, we must not shut down the executor
service if it belongs to the context.  We only shut down an
executor that we created specifically for the server.

If the server has no thread pool configuration, the context's executor
service is now used by default.

If a subclass provides a custom executor, we want to shut it down, but
if the context's executor is used, we must not shut it down.  The
revised test covers both cases.

The SocketRemote component doesn't want/need to allow the user to
provide a thread pool configuration, anyway, so we might as well use the
executor service provided by the context instead of creating our own.