Calling abort() has multiple advantages. First, it better matches the
semantic of DIE(_MSG) as it signals an abnormal process termination,
whereas exit() is a normal process termination (even though
potentially with an error exit code). Secondly, abort() throws
SIGABRT, which in turn triggers a coredump, hence the program's state
can be inspected afterwards.

[LAWS/Fiber] Introduce the concept of Multi-Fiber

See merge request i4/manycore/emper!195

LAWS, and similar scheduling strategies, only need to perform
refcounting and atomic operations if the fiber was placed in multiple
ready-lists in the first place.

Already check if fiber is runnable in scheduliing subsystem

See merge request i4/manycore/emper!197

Already check if the fiber is in-fact runnable in the scheduling
subsystem. This should not make a difference when WS scheduling is
used, but makes a difference when LAWS is used.

[meson] propagate set_affinity_on_block

See merge request i4/manycore/emper!194

[LawsScheduler] Guard Runtime::getWorkerId() with CallerEnvironment

See merge request i4/manycore/emper!192

[IO] remove Future affinity awareness which is done in Blockable

See merge request i4/manycore/emper!193

Set affinity on block

See merge request i4/manycore/emper!191

Calling Runtime::getWorkerId() is only possible from within the
runtime, hence guard the call with CallerEnvironment.

[IO] set the affinity of Fibers created by the completer thread

See merge request i4/manycore/emper!188

Set the affinity for Fibers created from the completer thread
to the workerId where the completion originated from.

First, we split up the Callback type in a user facing and an internal one.
The internal one has a new affinity member which provides the memory for
the new Fibers affinity buffer. This is memory safe because the Callback
object is always heap allocated and freed when the CallbackFiber terminates.

Second, each Future has an affinity member as well which will be passed
to the BinaryPrivateSemaphore when calling signalFromAnywhere to
again hint the originating worker.

Both affinity values are set during the preparation of the Future in
IoContext::prepareFutureChain because then we are sure in which worker's
IoContext the completion will be generated.

First of all I think it makes sense for laws to also look at affinities of Fibers
scheduled to the AnywhereQueue.
But the actual reason is that IO completions scheduled from the completer
could be dispatched from the priorityQueue before they are found in the
expensive AnywhereQueue.

But this comes with the cost of a vcall for scheduleFromAnywhere.

Using the STL iterator based approach has caused more harm than it
has advantages.

First of all it is unneeded we know how the Fibers we want to schedule are stored
and don't need a algorithmic generic abstraction.

We keep Fibers pointers in continues memory for memory locality benefits
therefore we can simply use the C dynamic array style of passing the
Fibers to the scheduler.

This removes the template from the batched schedule methods and allows us
to use virtual functions to specialize the batched scheduleFromAnywhere
method.

[LAWS] Set fiber affinity *before* dispatching it, not after

See merge request i4/manycore/emper!189

[Blockable] Support worker affinity in PrivateSemaphore.signalFromAnywhere()

See merge request i4/manycore/emper!187

[EchoClient] don't include shutdown duration in echo duration

See merge request i4/manycore/emper!181

I do as IWYU guides.

* 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

Make decision how many workers to notify in Runtime

See merge request i4/manycore/emper!183

The decision how many workers should be notified on new work should be
made in the runtime.
This is the whole reason why WorkerWakeupStrategies provide notify{One,Many,All} functions.

This change also simplifies the logic used in SemaphoreWorkerSleepStrategy.
The old simply copy-pasted semaphore based implementation could then
be split up into much smaller and simpler pieces.
SemaphoreWorkerSleepStrategy::notify{All, Many} is could actually be faster
because it can now use the semaphores notify_many function instead of
calling notifyInternal multiple times.

[check-license] exclude subprojects and use year and git user.name for autofixing

See merge request i4/manycore/emper!185

[Runtime] disable worker pinning using EMPER_DISABLE_PINNING environment variable

See merge request !182

[WorkerSleepStrategy] call the correct implementation method

See merge request !184