API design for rule program analyses and/or transformations

Besides materialisation, there are many further things that one can do with a given logic program, such as running acyclicity checks #610, but also program transformations of various kinds can be conceived. The common aspect of these actions is that there is a rather large number of them, and that there can always be some more in the future. This raises some software design issues:

• Implementations for the various actions should be as modular as possible, without traces of action-specific code or data in the regular objects.
• It has to be thought through how to make these actions available in the API. Currently, we are having a reasoner object as the main entry point for calling materialisation, but we should not have a method for every possible action in this struct.
• Some way for making such actions accessible through the command-line needs to be designed, again in a somewhat modular fashion.

Start with the reasoner object and its current materialisation entry point, then review how the proposed rule-program actions could remain modular. Consider the API and command-line access together, including how future analyses and transformations can be added without action-specific data in regular objects. Done means the design addresses all three concerns: modular implementations, extensible API access, and modular CLI access.