REFAC: PbdConstraintFunctors and Containers
This change adds PbdConstraintFunctors and Containers. This change is just a step in the right direction, there is much to be done. But this allows us to do some new things and move on with projects.
1.) The PbdConstraintContainer takes on most of the code the PbdModel was doing for adding/removing constraints. It will serve as the central point for adding/removing constraints.
- With a separate class for this it also becomes easier to change the internal implementation in the future.
- It could even see polymorphism in the future.
- The PbdModel should not worry/know about containers and other implementation details.
2.) The PbdConstraintFunctors move most of the code that was adding constraints to separate structs functors. This is the big requirement from this MR. This makes them extensible allowing users to add custom functors which add custom constraints or existing ones in different ways.
Ex: You could implement a functor that adds constraints for a particular geometry in your program that reads a mask and only adds constraints for certain parts of your geometry.
Ex: You could implement a functor that adds custom (user) constraints.
The PbdConstraintContainer should eventually be moved out of the PbdConstraint library. It is not meant to be a general container for pbd constraints. Though it can be used standalone, it needs to be there for solvers right now. So it's very difficult to move out.
The PbdModel::addConstraints by vertex should be refactored eventually (once its branching/cases can be dished out to the functors).
There really shouldn't need to be getters for the underlying containers used in the PbdConstraintContainer. This would involve implementing custom iterators as well but for parallelized code this is not easy given the varying data structures (graph coloring) and parallel iteration requirements.