las3_pub / predictable_parallel_patterns

We separated the structure (input-output flow) from the rest of the architecture and reworked some template programming to have better access to the types required at compile time.

The data can now flow into a graph, follow its path on inptus/outputs and be fetched from the graph after execution.
Currently graphs are executed synchronous.

We need some tricks in template programming to have a clean user facing API while internally using our classes with more capabilities.

This is the base building block for creating the actual dataflow functions and networks, as their main functionality is having data flow through connected nodes.

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

Now all algorithms are used without the parallel pre-/suffix and the for_each method has an specialization for integer ranges.

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

The __thread implementation of thread local, static variables seems more efficient, so we activate this by default. If it is (for some reason) not available/slower than the pthread version, one can toggle it for the specific system/processor later on using macros.

We do this to properly separate the cache alginment logic in the next step, allowing us to port all cache aligned objects without worrying about portability.

We do so by pulling out the profiling macros in our own iclude file. In the future we might even be able to use this to build up further visualisations of the executing programm.

There are serval ways we could optimize the calls, but for now this should be enough for first tests.

This requires the user to explicitly manage the storage duration/place of the thread local state, making a fine grained memory allocation simpler.

We force linker errors if the new operator is used somewhere. See NOTES.md for details.

Seperate library from other parts of project (samples, playground, testing, ...). We still are in one 'toplevel' cmake project, so we can for exmaple compile everything (library and playground) in debug mode, for simple development.