However this does not fully solve an issue (shared camera data and XPA
server give a different camera state) when the camera is stuck at
initialization.

This makes calls like tao_rdlock(errs,obj) automatically dispatch
according to object type.

Shared objects are built on top of `tao_shared_data_t` instances which
provide a mechanism for r/w locking the resource.  The code for
finalizing shared resources is simpler because we can assume that
the mutex associated to shared data is always owned for a short period.
This will also simplifies getting images from a remote camera: semaphores
will no longer be needed (code compiles but is broken for now in that
respect).

Most functions return a `tao_status_t` to represent success, error or
timeout.  This simplifies and unifies calls to functions with a duration
limit.  This makes the code more clear about the intention:
`foo(...) == TAO_OK` is much better than `foo(...) == 0` or, worse,
`!foo(...)`.

Virtual frame-grabber and shared camera now provide information about the list
of shared arrays created by the virtual frame-grabber.  This is to imporve
efficiency of clients which no longer need to systematically attach posted
images.  It has also been clarified that the `counter` member in shared arrays,
in virtual frame-grabber structure and shared cameras reflects the number of
images posted by the virtual frame-grabber.  Then the index of the shared array
in the list is given by:

    index = (counter - 1)%length

where `length` is the length of the list and providing `counter > 0`.

A number of members in TAO structures have been qualified as `volatile` (those
which may atomically change) or as `const` (those which are immutable).

This involves lots of changes:

- Andor cameras are instances of `andor_device_t` which extends `tao_camera_t`.
  This is similar to Phoenix cameras which are instances of `andor_device_t`
  which also extends `tao_camera_t`.

- The API for `tao_camera_t` had to be adapted.  The underlying principles are
  clarified in the documentation.

- Virtual methods for Phoenix camera have been updated accordingly.

- TAO core library provides more routines useful for servers.

- Phoenix server has been modified and simplified.

- Andor server has been rewritten and is much more similar to Phoenix server.

- Thanks to the (updated) unified camera API, controlling camera acquisition is
  more simpler and more consistent.  The code for the servers is also simpler.

The code compiles with no errors but bugs are expected.  A great deal of the
code for the Andor and Phoenix servers is identical.  This code should be
shared.

Camera `state` member is replaced by a `runlevel` which is used at high and low
interface levels and has more possible values (e.g. to dsitingusih between
recoverable and unrecoverable errors).

The semantics of calling the virtual camera methods is better explained and
more consistent.  As a result, the low-level interface is easier to write.
This has been reflected for Phoenix cameras (not yet for Andor ones).

To simplify management of commands, a single event is associated to having a
pending command and, at any time, there can be at most one command.

Minor edits for readability.

This API is similar to the ScientificCameras Julia package.  It is intended
to provide basic structures and functionalities common to any kind of
cameras.

See "tao-camera.h" for definitions and "cameras.h" for implementation.

There are a few side effects:

 - `tao_(|try_|timed_)wait_image` -> `tao_\1wait_remote_image`;
 - member `depth` replaced by `sensorencoding`;
 - new member `bufferencoding`;
 - member `eltype` of remote cameras replaced by `pixeltype`;