- The macro is getting the name from the test suite, which is done with a #define. At this point the auto-formatter puts spaces in between because it thinks its a minus sign.

Test accomapnying the previous fix that if data on incoming variables is
sent out via ZMQ and data matching was none that there will be an event
id attached to it

Also, for the "trivial" datatypes such as scalar, array, IFFF enable
attaching a macropulse number on incoming variables so we can send out
updates from e.g. JDDD panels out via ZMQ

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