Addtional configuration options for sifting appender.

This change adds 2 configurable attributes to AppenderTracker and hence
SiftingAppender.  The first is maxAppenders, which limits the number of
sub-appenders the SiftingAppender will have open at any given time.
This can help prevent resource exhaustion such as running out of file
descriptors or other resources consumed by the appenders.

The second configuration option is timeout, which specifies the time
in seconds after which a sub-appender will be closed if it has not been
written to.  Previously, this value was hard coded to 30 minutes.
This option addresses RFEs http://jira.qos.ch/browse/LOGBACK-244
and http://jira.qos.ch/browse/LOGBACK-724.

These configuration options are specified as the "maxAppenders" and
"timeout" attributes on the <sift> element of logback.xml respectively.
Switch maxAppenders and timeout configuration to use elements instead of attributes.
fix LOGBACK-831
Merge branch 'master' of github.com:qos-ch/logback
replaced references to "remote logger" with "remote receiver"

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.
added ReceiverBase for receiver implementations

The existing SocketRemote and SocketServer classes will be refactored to
descend from this base class.
Transformed SocketRemoteAction and ServerAction into ReceiverAction

ReceiverAction can instantiate a component that is a subtype of
ReceiverBase.  SocketRemote and SocketServer will be refactored to
extend the ReceiverBase type.
added SSLComponent interface to identify SSL components for config

This will eliminate the need to add a nested component rule for each new
SSL component.
modified nested component rules to use new SSLComponent interface
modified JoranConfigurator to use new SSLComponent interface
refactored SocketRemote to extend ReceiverBase

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

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.
a receiver now has-a Runnable, no longer is-a Runnable

This will make it easier to refactor SocketServer so that it extends
ReceiverBase.
refactored SocketServer so that it extends ReceiverBase
ReceiverBase.start now creates executor before calling shouldStart

The subclass may need a reference to executor to pass to objects that
will need it later when the receiver is running.
reworked examples replacing to "server" and "remote" with "receiver"
ReceiverAction now casts to ReceiverBase, not SocketReceiver
updated docs to account for receiver component type

Still needs lots of proofreading...
Merge remote-tracking branch 'origin/receiverComponent'

This branch refactors the previously contributed "server" and
"remote" components such that they now extend a common "receiver"
component.  A receiver is a component that receives logging
events from a remote appender.  A connection between and an
appender and a receiver may be initiated in either direction;
i.e. a receiver may initiate the connection to an appender or
vice-versa.  The receiver component is configured in Joran using
a <receiver> element.  The class specified in this element
determines whether the receiver will passively await connections
from remote appenders (i.e. as in the legacy SimpleSocketServer)
or whether it will initiate a connection to a remote appender
(a ServerSocketAppender).
reduced timing sensitivity in ConcurrentServerRunnerTest