Visualizer Refactorization

[zkwip]

Perhaps it is a good idea to change the visualization structure to allow visualizers to be nested, this could make it easier to add more complex visualizers in the future and improve code reuse, but I don't know how many more visualizers we will need, only some menu-like things come to mind but they probably don't need to be nested anyways

[zkwip]

This is actually not a single problem that can be solved with just nested instances. We have the following problems

• The control flow for rendering decides what needs to be updated or fully drawn.
• There are components inside each other that use the same data set and would thus have the same visualizer type.
• The change-rendering code depends on knowing the previous state.
• Mutual execution is intertwined with the full-or-update control flow.
• Scrolling the board is also intertwined with the full-or-update control flow.

This all does not mean we shouldn't refactor it, but rather confirms it.

The mutual execution flow should for example be separated out first, and then the appropriate data structures should be picked and the control flow and file structure should be implemented

[zkwip]

Started refactoring a lot of things, the mutex flow is next

[zkwip]

The game control flow has been separated into control classes

[zkwip]

Refactored all visualizers to inherit from a common class, to simplify the structure and now all of them support the mutex system from the board visualizer, without effort.

However we do not use the full set of features. For example, the menu visualizer does not make use of RenderChanges.

[zkwip]

The visualizers cleaned up quite a lot but it is probably a good idea to add the nesting in too because at the moment there are more and more features that render outside of the visualizers. Rendering outside the Refresh could easily reintroduce the mutex issues