Release of TCA Version 8.2

Summary:
========

TCA now keeps track of which broadcast messages have handlers registered
and only broadcasts a message if there is a handler.  This is all done
in a manor transparent to the user.  You don't have to change any code
to take advantage of this feature.

There is a new function call that a module can use to indicate whether
it will listen for tca messages, tcaWillListen(int listen).  Calling this
function allows module to run more efficiently in some cases.

All tca internal messages have names that start with "tca_".  This will
make it easier to distinguish system messages. For compatibility, the
old message names are still supported.

The "context" switching has been improved and allows a process to connect
to multiple central servers and forward query and command messages as
well as broadcast messages.  This work was done in preparation for a
more generic messaging bridge.

The tcaDevice in the devUtils package has been improved to handle
multiple central servers as well.  The interface mostly remains the
same, except that the internal data structure, TCA_DEV_TYPE, is no
longer exported.  The only inconsistency is that TCA_disconnect now
takes a TCA_DEV_PTR rather than a DEV_PTR.

Replace:
      TCA_disconnect(TCA_device->dev);
With:
      TCA_disconnect(TCA_device);

The TCA_connect function now returns a TCA_DEV_PTR that can be used on
subsequent calls.

The following functions are new or have changed:

void TCA_setCentralHost(const char *machineName);
 - Set the host name for the central server.  Call this before calling
   TCA_connect to connect to a central, other than the default central.

DEV_PTR TCA_getDev(TCA_DEV_PTR tcaDev);
 - Function to return the device pointer for a tca device.

BOOLEAN TCA_isConnected(TCA_DEV_PTR tcaDev);
 - Now takes a TCA_DEV_PTR so it can be used with multiple central
   servers.

Details:
========

The central server has a list of all messages and handlers.  When a
module starts up, it requests a list of broadcast messages that have
handlers registered.  It then checks this list to see if a message has a
handler before broadcasting the message.  If the list of broadcast
messages with handlers changes (new ones added, old ones removed), then
central informs the modules of the new list.  This all works
transparently to the module programs.

There is one catch. The module programs have to call tcaModuleListen or
devMainLoop or call tcaHandleMessage periodically.  This is to ensure
that the message informing the module of new broadcast handlers is
processed.  If a module registers a message handler, TCA assumes that it
will have to check for this message and will also get the broadcast
handler list message.  If a module does not register any message
handlers, then the module reverts to the original behaviour of always
broadcasting messages since it will not have an up to date list of
handlers.

The new function call, tcaWillListen(int listen), can be used to
explicitly tell tca whether the module will listen for messages.  In
addition to helping improve the efficiency of broadcast messages, it can
also help with logging and direct connections.  When the state of
logging changes, the central server informs the modules so they can
redirect direct messages through the central server so they get logged.
Otherwise, the modules do not get updated logging information.