* Pass the IO results on the stack instead of storing them in the
  client object.
* Terminate the runtime on quit to print stats.
* Free Client objects.

Each worker thread has it own stringstream per ShardedFileBuffer.
All streams are joined and flushed to the file when a ShardedFileBuffer
is destructed.

Flushing a ShardedFileBuffer is not thread-safe and must not be called
concurrently to any modifications to the ShardedFileBuffer.

Use a ShardedFileBuffer to accumulate and print all paths during fsearch.

In the emper-fs-eval I would like to validate the output of the fsearch
variants against a list of known files. Not writing any log messages to
stdout make that easier.

Use -1 as the offset of the write to stdout.
Passing offset -1 means to use the file's implicit offset just like write(2).
When using a tty as stdout offset 0 is fine but when redirecting stdout
to a file 0 will cause that previously found paths will always be
overwritten.

Thanks to Nicolas Pfeiffer for writing the initial prototypical
implementation of continuation stealing and the cactus stack
mechanism, on which this is based.

Co-authored-by: Nicolas Pfeiffer <pfeiffer@cs.fau.de>

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