No test yet, hence ticket added on github #63

Reason: otherwise error messages are sometimes appearing at server start/shutdown because sending is not possible at that time.

If a header-only library requires linking a 3rd party library, the ..._LIBRARIES variable could not be used in depending projects, because it
contained NOTFOUND.

this will be cleared once the initial value has been received

Removed libtine linking workaround from FindDOOCS. Doocs libraries now are themselves linked correctly against tine.

Without this optimisation, the llrfctrl server fails to process its updates in time and massively loses data.

Test module for confirming that value changes on ConstrolSystemAdapter
defined doocs types are propagated to its zmq subscribers.  Intended for
cases where the value change happens through the doocs system (like
through the doocs panels, EqFct::set etc..).

Tested:
  - DoocsProcessScalar

Pending tests:
  - DoocsProcessArray
  - DoocsSpectrum
  - DoocsIfff

dmsg_info.ident is set to 0 when DoocsProcessArray and
DoocsProcessScalar do not have a macropulse source defined.  This is
what the other supported types do currently; behavior should be
consistent between the types with this commit.

Revert this if it is not the intended behavior.

Use macros below without needing to import the boost::unit_test
namespace:
  - DOOCS_ADAPTER_DEFAULT_FIXTURE
  - DOOCS_ADAPTER_DEFAULT_FIXTURE_STATIC_APPLICATION_WITH_CODE

The adapter publishes value changes made from the control system side
for the following types:
  DoocsSpectrum
  DoocsIfff
  DoocsProcessArray
  DoocsProcessScalar

This fixes some spurious failures, potentially caused by making the ZeroMQ connection too early

DOOCS now sends initial value polled via RPC, but this one is still asynchronous to the ZeroMQ subscription. Hence to be sure our test works we still need to wait for this initial value and then check that values are coming through the ZeroMQ subscription.