Integration of the CachedBuildSideMatchDriver into the optimizer

I have redone the integration of the cached match driver. It is now integrated into the optimizer instead of just switching the DriverStrategy in the NepheleJobGraphGenerator. I feel it is much cleaner this way.
So this pull request replaces #822. 
Instead of extending the cost model like proposed in #795 the cost estimation function get passed the number of iterations, so that you can decide for every operator on its own how to incorporate iterations.

Do we need those flags?

Would it be sufficient to identify situations for the cached hash tables by finding joins where on part is on the static path, one part is on the dynamic path?