Answer count model for reasoner planner

[krishnangovindraj]

What is the goal of this PR?

This PR introduces the stats based answer count estimation which is the basis of the costs of reasoner plans.

For a given conjunction, We aim to estimate:

• The number of answers for a given (sub)set of variables
• when considering only a subset of resolvables of the conjunction

We believe this is sufficient for our formulation of the reasoner planner's cost function.

What are the changes implemented in this PR?

reasoner.planner.AnswerCountEstimator$ConjunctionModel:

• Given a conjunction, builds a model and answers queries to estimate answers for
  • The number of answers to a subset of variables
  • Considering only a subset of the specified resolvables in the conjunction. reasoner.planner.AnswerCountEstimator$ConcludableModel:
• The basis of

reasoner.planner.AnswerCountEstimator:

• Registry of ConjunctionModels
• Coordinates between them while inter-dependent models are being built

reasoner.planner.AnswerCountEstimatorTest:

• TestCases for concludables & conjunctions verifying the estimates are as expected.

[grabl]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.