Feature/issue 39 counting model improvements

[ellmau]

What does this PR do?

Improves the performance of the stable model computation, by using more bdd-related information, such as

• number of paths in a BDD with a specific outcome
• variable impact
• maximal depth of the BDD

Checklist before creating a non-draft PR

• All tests are passing
• Clippy has no complains
• Code is rustfmt formatted
• Applicable labels are chosen (Note: it is not necessary to replicate the labels from the related issues)
• There are no other open Pull Requests for the same update/change.
  • If there is a good reason to have another PR for the same update/change, it is well justified.

Checklist on Guidelines and Conventions

• Commit messages follow our guidelines
• Code is self-reviewed
• Naming conventions are met
• New features are tested
  • quickcheck has been considered
  • All variants are considered and checked
• Clippy Compiler-exceptions
  • Used in a sparse manner
  • If used, a separate comment describes and justifies its use
• rustdoc comments are self-reviewed and descriptive
• Error handling
  • Use of panic!(...) applications is justified on non-recoverable situations
  • expect(...) is used over unwrap() (except obvious test-cases)
• No unsafe code (exceptions need to be discussed specifically)

[ellmau]

As already mentioned in commit 6a47f4d, the mentioned instance takes very long to compute the models (cancelled computation after 4h waiting time).

First checks on the results of the trace-output show that the problem gets trivial in roughly 20 steps with an comparable small amount of positive/negative paths in the BDD. This makes the long runtime even more questionable.