Improvements In Constructions. Solver Step Will Compute References

Some changes will be specially made to explicitly show side effects in code. As most of .Net developers (or C++ or Java on that matter) know that they create references by default, this have nice properties, mostly that avoid to make too many copies, but sometimes is hard to find where you did modified your content. Also for helper classes, like for example decorators (classes that simply call for you one API that is harder to use and will expose a simpler one) can be really convenient to be created but on the same time they can have side effects are even harder to find for the internal code.
So for this reason, an utility class that was used to work as a reference class, namely NodeBuilder, will become a struct type. This will make errors to be more strict and error handling much clear: is not possible to have null values, and the copies are explicit.
A small good side-effect of this change is that if theoretically a developper will want to make all shapes colored red, in the past will do like:
foreach shapesNode in scene do new NodeBuilder(shape).Color =Color.Red
The new code will be the same, but will not create garbage objects.
Another good change is that if you have a shape, is really easy to see which shapes are referenced, but is really hard to find the shapes that are referring your one.
For example: there are a rectangle, an extrude on top of it, and it's height is constrained.
If you have a reference to extrude, you can check by looking to extrude's shape content (for example using a NodeBuilder) which shape is built on, but to find which shapes are are constraining your extrude height, you have to literally look to entire scene.
For now I've did the change that at every shape change, when is computed the Solver step, in the same passing and having guaranteed O(n) (where n = number of shapes) time, a graph list is copmputed. This will make possible (is not yet made the migration) to accelerate and clean the code in constraints area (that will iterate over all nodes to see which is the shape is applying), delete code and in general will make less computationally looking backward in your internal referencing graph.
I made this structure anyway for wanting to make a chaing-based shape where the shape is made of a chain of small shapes (more of this will follow), so when you will click on an item, you will automatically want to know which are the list of shapes that make the full shape.