Fix combinational sensitivity excessive pessimism, fix #233

[mkorbel1]

Description & Motivation

Issue #233 finds that searches for Combinational sensitivity lists, it is excessively pessimistic in that sometimes there aren't really any combinational paths, but it assumes that there may be. This can cause an issue where a false combinational loop is detected, causing incorrect X-generation.

This PR fixes the bug by calculating more detailed combinational paths for Modules at build time. This information can be leveraged by Combinational to understand more accurately where combinational paths may exist. Results are cached to avoid repeated calculations when multiple Combinationals search through similar paths of potential sensitivities. All Modules with custom functionality must explicitly define any combinational paths from all inputs to applicable outputs or else Combinational will be unable to properly determine an accurate sensitivity list. A new FullyCombinational mixin is included in this PR to automatically add all input/output combinations as potential combinational paths, since that's a common case for many small custom gates.

Additionally,

• Added RohdException base type for all ROHD exceptions, making it easier to handle ROHD-related exceptions
• Added new ModuleNotBuiltException, used in multiple places in Module

Related Issue(s)

Fix #233

Testing

• Added a new test that had reproduced the original issue without this fix.
• Existing tests cover scenarios where non-trivial sensitivities exist.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

Other custom functionality modules defined outside of the ROHD framework which had previously benefited from assumption of the behavior of FullyCombinational will now be treated as the complete opposite (no combinational paths). This could mean Combinationals would now be missing sensitivities that previously existed. If those sensitivities were true, then existing simulations in ROHD might now have incorrect behavior. This is likely rare, and since this is really a bug fix it doesn't quite feel like it's breaking backwards-compatibility.

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

Doc comments updated/included