this will be cleared once the initial value has been received

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.

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

This avoids multiple map lookups.

This is a workaround for the following DOOCS bug:
https://rt-system.desy.de/Ticket/Display.html?id=985653

All IFFF sources must be consistently readable/writable. A logic error
is thrown if this is not the case.

* compiles but untested
* existing tests for app->CS still passing.

- Shows up in Doocs
- Test does not check functionality yet, just that it's there

- was confusing milliseconds and microseconds for the archiver
- was not setting the global time stamp

By default, the timestamp that is attached to a variable is the global time stamp, which is only set updated by update() in the adapter, which is not used otherwise.
The adapter already was setting it for the time stamp that is attached to the variable itself, but not for the time stamp that used for archiving. This has been fixed. Now the time stamps in the Doocs histories are set correctly.

To test it run example2 of ApplicationCore, togehter with the oven_sim simulation and watch Oven.heatingCurrent.HIST

output warning if data is thrown away due to failed consistency matching between macro pulse number and actual data

Workaround for the svr_writer thread (of DOOCS) to block location mutexes for a very long time if many big D_spectrum are written. The write is now only done if necessary (i.e. after a modification) and the lock is released for a short period of time to make sure RPC calls don't get blocked for too long.

Allow to set the data matching mode. This for now only allows to switch off the DataConsistencyGroup matching for the attached macro pulse number.

Fixes #28

Started implementing consistent macro pulse numbers in process variables. Only scalars at the moment.
No dediacted tests yet, but adapted ZMQ test which failed.