Determine a repository-wide policy for argument checking

[fsaad]

CGPM is written very defensively in that methods throughout perform significant error checking on their inputs (sometimes as assert but typically by raising a ValueError.

Advantages:

• comprehensible error messages at runtime
• serve as good reminder of method expectations when revisiting code.
• can easily test software behavior on unexpected input.

Disadvantages:

• significant code complexity
• maintenance cost
• function call overhead can be non-trivial.

This issue is partly (but not entirely, since we check the relationships between arguments at runtime) related to python being a dynamically typed language. In practice, such problems are typically solved using some form of static analysis and program verification (e.g. predicate transform or abstract interpretation) except I wonder whether how well these tools would work for a complex set of predicates such as especially equality between data structures that are specified only at runtime.

Either way, we need to determine whether CGPM should keep these checks. If yes, it might be worth thinking of some strategies to reduce the complexity of these useful checks.

[fsaad]

After refactoring significant parts of CGPM d059525 I found the error checking code to be essential in debugging, which makes me lean toward maintaining the current status quo with some improvements that reduce error-checking duplication.