las3_pub / predictable_parallel_patterns

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.

This removes boost as an dependency from our code and makes our project
again only dependent on C++11 compilers (no external dependency).

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.

These currently do nothing but being boilerplate required to implement a new top level task.

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.

This lead to some bug-fixes that covered move constructors not correctly assigning memory. We might clean this up further by only allowing in place creation of these types (placement new).

The current solution is not clean, but allows us to change error handling later on without missing any point in the programm where we would want to use it.

This implementation allows one to add the deque_item property to any class and then manage pointers to these items in a deque. We currently use a spinlock for concurrent access.

This means that high level tasks can be stolen and lays the groundwork for implementing different tasks like classic work stealing.

This will be used for storing thread tasks aligned in continous memory, allowing different theads to work on the data without interfearing.

Right now no work can be spawned, we simply have a proove of concept that we start up each thread, work for the master to finish and then synchronize back to the main thread.

See NOTES.md for details, basically std::thread can use dynamic memory allocation internaly and we want to prevent that.