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.

This avoids multiple map lookups.

This reverts commit 72d93ba1.

A different fix for the underlying problem will be implemented next.

Automatically adding CMAKE_CXX_STANDARD to all projects is giving too much trouble because different CMAKE versions add different --std=gnu... flags which do not play well the the --std=c++... which we use.

This reverts commit ddb4d575.

they still appear sometimes, which frequently leads to wrong conclusions when debugging other problems

If the macro pulse number is also published as a property, it is used with and without the decorator. This might result in not calling postRead of the decorator, if by chance the undecorated version is added first to the DoocsUpdater.