Now three variants of computation are available:

* fixed (echoserver <port> <computation>:
   This will always consume computation us before sending the echo
   back to the client.
* random range (echoserver <port> <computation> <computation-max>:
   This will consume a random computation uniformly selected
   from the interval [computation, computation-max] us.
* random min-max (echoserver <port> <computation> <computation-max> <max-probability>
   This will either consume computation or computation-max us.
   The max computation is randomly chosen with the specified probability.

All random values are generated with a thread_local mt19937 generator
and uniformly distributed with uniform_{int,real}_distribution.

This is needed by emper-io-eval because apparently our startup/termination
times are shorter than the OS allows the rebinding of the same tcp tuple.

Also make all global variables static because they don't have to be exported.

The Coordinator is used for our echo evaluation and implements
a barrier style synchronization mechanism for processes spread across the network.

Check if std::filesystem::recursive_directory_iterator and std::filesystem::path
are available before using those in EMPER code.

We do not export the symbols using the not supported filesystem features
in our public headers using preprocessor ifdef.

But the code in the cpp files using it not removed using the preprocessor.
To allow linkage we use a constexpr which throws a logic_error on runtime
rendering the rest of the code dead und thus prevents its generation by
the compiler.
This methods allows the compiler to see the code in its analysis passes
but does not fail during linking.

Allow meson.build files in emper/ subdirectories add configuration options
by consuming the conf_data object after all subdirectories were visited.

Introduce a quasi naming standard for cpp feature flags in meson code:
	cpp_has_<namespace>_<feature>

Examples:
	cpp_has_fs_path

* Merge the two echo functions echo and linkedEcho into a single templated
  Client member function _run(). This reduces code duplication but the resulting
  echo loop is less readable because of more if constexpr switches.
* Move more code out of the echo loop into separate functions:
  * unexpected echo message
  * on ECONNRESET handling
  * error handling
  * termination condition

* Shutdown the client connections after the echo phase has ended.
* Send "quit\n" on the last client connection (Though it is not guarantied
  that there are no more open connection because we parallelize the termination)
* Free memory after the Runtime has terminated

The break was not in the right scope and thus exiting the echo loop
immediately in the first iteration.

Since stats are printed in the Runtime destructor we can not simply call
exit() and have to properly terminate the Runtime.
When the echo server receives a "quit" message all active connections will
return and the Runtime will terminate if there is no work left.

Histograms can only be collected when using a fixed amount of iterations.

When the '--histogram <file>' argument is passed each Client
collects 4 time stamps (each 8 byte):

1. Before requesting the send operation
2. After requesting the send operation
3. After getting unblocked and dispatched because the send operation finished
4. After getting unblocked and dispatched because the recv operation finished

Taking the timestamps is enabled using a template and thus does not introduce
any runtime cost if they are not used except binary size.

Before termination three latencies are calculated and written to the histogram
file as csv data for each client and each echo.

1. total_latency := (T4 - T1)
2. after_send_latency := (T4 - T2)
3. after_send_dispatch_latency := (T4 - T3)

This makes looking at individual experiment results and identifying
outliers easier.

Split output between two ini sections: global, clients.
The global section includes results like:
Arguments, total time spent in each phase, ...

The clients section contains a sigle key 'csv' containing the csv data
from each client inclufing the header:
iterations, latency, reconnects, unexpected echos

This leaves the post processing of the data to another program
and does not hide experiment behavior (e.g. starvation of single
clients) behind averages.

Remove support for appending to an output file, because we do not
use it in our emper-io-evaluation and it does not work anymore with the
new output format.

* Unconditionally reconnect when the TCP connection was reset and count the reconnects
* Send Client id and iteration in each echo
* Use a Client class holding a clients state instead of a pthread style clientFunc
* Create the Client object in the client Fiber to use NUMA first-touch policy
* Reduce code duplication:
  * starting a new Client is now done with Client::startNew
  * latency measurement and error handling are moved from the clientIteration*
    functions in the Client::run function

My first test runs don't show unexpected echos. Therefore I think
unexpected echos are rare and their average will always be 0 even if
some sparse unexpected echos occur.

* Use emper::lib::math::RunningAverage instead of doing it manually
* Count the unexpected Echos, print a error to the log and go continue
* Return a duration and error message pair from our clientIteration* functions
* Print the current iteration on error
* Wait 10 seconds after an error before terminating

Build up output string and don't incrementally output it to stderr
to hopefully prevent error messages interleaving.
Only output the least significant byte of the unsigned int cast.
Always use two digits per byte and remove the whitespace.
Should have used printf in the first place.

Rename the macro used to build up the debug message, to better reflect
its generality.
It can be used anywhere to build a string with C++ stream formatting.
std::string s = EMPER_BUILD_STR("foo = " << 1 " , bar = " << bar(42));

Since WDBG was the only log macro without a terminating newline, which
was in fact broken according to flow, we can remove it and the new line
handling code in the LOG macro.

While we haven't figured out why the version using linked futures breaks
we can use a simpler implementation which calls submitAndWait on both futures
separately