DPL: introduce a --data-processing-timeout

[ktf]

Used to force stop the data processing and start the calibration.
In case it is larger than the exit-transition-timeout, the two will be coalesced
into a single transition.

For the time being the only side effect is to set the DeviceState::allowedProcessing and
to terminate the source devices earlier than the data processing ones.

Next PR will make sure that only calibrations are treated when DeviceState::allowedProcessing is set to ProcessingType::Calibration.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0

[ktf]

@teo @davidrohr @shahor02 this is the first one of two PRs to enable the new calibration mode, as requested in https://its.cern.ch/jira/browse/O2-4308. This one in particular implements a new timer, configured via --data-processing-timeout, which will trigger the dual timer for non-source devices and make the sources transition to end of stream earlier. If the --data-processing-timeout option is omitted, it will behave as usual.

Notice that even if the dual time is there, for now it's merely printing out a different message and setting the DeviceState::allowedProcessing to CalibrationOnly, it will not yet enforce the new behaviour of discarding the non calibration inputs. The latter is coming via #13544, which I am still refining.