las3_pub / predictable_parallel_patterns

If they are required in future iterations they can be re-added from the history, however,
for now it only confuses project users as it is not clear which data structures are actually in use.

I am not sure if this is appropriate, but it works and is no focus of this project.

Make sure that the guard page leads to sigsegv as expected.

Remove the strict static memory allocation scheme in favour of placing objects on the heap at startup. This still keeps the requirements posed for modern, high performance embedded systems, but makes APIs a lot cleaner.

The current version has race conditions and is hard to debug (especially because of the fibers, if a wrong thread executes on a fiber we get segfalts very fast). To combat this mess we now refactor the code bit by bit while also adding tests where it can be done with reasonably effort).

The start_chain property does not make sense, as chains are purely 'virtual', i.e. they only fully exist when walking through the computation (by patching them on important events). We initially added the property as a helper for better runtime and simpler implementation, but we think without it we will not get as much inconsistency in the runtime state. Performance can be 're-added' later on.

Everything so far is untested. We only made sure tha fast path still seems to function correctly. Next up is writing tests for both the fast and slow path to then introduce the slow path. After that we can look at performance optimizations.

This showcases the expected performance when a task executes a sub-tree without inference from other threads. We target to stay about 6x slower than a normal function call.

This allows us to more easily handle them and makes their interface closer to std::thread.

The scheduler yields if it failed to steal any work due to the task
lists being empty. This should improve performance on multiprogrammed
systems, as it potentially makes room for other worker threads which
still have work to perform.

This allows the stack and deque class to use the same offset, making it work better with each other.

Threads must be joined on scheduler termination and tasks must be pushed onto the stack to allow better memory management.

This seems to be only possible with two different function names, as variadic arguments and default arguments wont work together.

Please note that this does currently not execute, but only removed the 'old aspecs'. We are still missing launching the root fork_join task.