Added the member variable m_vdqmRequestHandlerThreadPool to make the design and structure of the code more explicit

migrations.  Fixed a bug with a mix up of sockets.

  GatewayTxRx: Sends and receives messages of the gateway<->aggregator protocol.
  RtcpTxRx   : Sends and receives messages of the RTCOPY prototcol.

Implemented the position, file transfered and end of recall parts of the
RTCOPY recall protocol.

the initial connection from RTCPD.  The main select loop is now in place so
that we can see many messages and connections at the same time.  However we
still have not seen the incoming connections we expect for the tape and disk
I/O threads.

will deal with the following:

     * The incoming callback connection request from the tape I/O thread.
     * The incoming callback connection requests from the disk I/O threads.
     * Any incoming messages sent from RTCPD over any of the connected
       sockets, including the initial RTCPD connection.

own function:

  castor::tape:aggregator::VdqmRequestHandlerThread::processJobSubmissionRequest

Started to refactorise out the giving of file lists to RTCPD.

have removed RtcpdHandlerThread.  The code compiles, but probably does not
work.

The concurrency and communication model has been decided.  There will be a pool of VDQM threads with one thread per tape drive.  Today there is only one drive
per tape server at CERN, but we are trying to keep backwards compatibility.
The existing code we are trying to replace kept open the option of more than
one drive per tape server.  One VDQM thread will use a select loop to
communicate with the five or more incomming connections required by RTCPD.  By
default, RTCPD makes five connections to a client.  The initial connection to
signal the start of a remote tape copy and to listen for ping and abort
messages, one connection for the RTCPD tape IO thread, and three connections
for the default number of three RTCPD disk IO threads.

The next step is to code the select loop for the five or more connections.

ackowledge of a request for a VID from RTCPD.  Still a long, long way to go,
but it's a start.

tape aggregator daemon.

C++ interface to DLF. This is supposed to replace the current logging facility without loosing the possibility to give objects to the interface.

Last version of the logging facility, now allowing to choose between No Log (default), DLF and stdout