Fix bug where Module.build didn't follow through structs containing ports properly, plus improved debug messaging.

[mkorbel1]

Description & Motivation

This PR has 2 main components:

• A fix for a bug which causes "trace errors" (PortRulesViolationException) when a LogicStructure contains a port of a Module.
• A greatly improved error message for PortRulesViolationExceptions which shows the full stack of signals that led to the exception, which should make it much easier to debug these types of issues.

Thank you to @desmonddak for finding this issue during development of intel/rohd-hcl#152

An example of the new format for a tracing error (in this case, a missing addInput):

Violation of input/output rules in module "missing_input_mod" (MissingInputRegistrationModule)  :  (b) on signal Logic(1): a. Logic within a Module should only communicate outside of itself by consuming inputs/inouts and driving outputs/inouts of that itself. See https://intel.github.io/rohd-website/docs/modules/ for more information. 
= Module "missing_input_mod" 	 [tracing from outputs]
  on input  port 	 Logic(1): a
  of sub-module	"top" (MissingInputRegistrationTopModule)  :  (a) => (b)
= Module "missing_input_mod" 	 [tracing from outputs]
  on input  port 	 Logic(1): _a
  of sub-module	"not" (NotGate)  :  (_a) => (_a_b)
= Module "missing_input_mod" 	 [tracing from outputs]
  on output port 	 Logic(1): _a_b
  of sub-module	"not" (NotGate)  :  (_a) => (_a_b)
= Module "missing_input_mod" 	 [tracing from outputs]
  on output port 	 Logic(1): b
@ Module "top" (MissingInputRegistrationTopModule)  :  (a) => (b) 	 [tracing from outputs]
  on output port 	 Logic(1): b
  of sub-module	"missing_input_mod" (MissingInputRegistrationModule)  :  (b)
= Module "top" 	 [tracing from outputs]
  on output port 	 Logic(1): b

There's also some doc updates and improvements in toStrings and messages.

Related Issue(s)

N/A

Testing

Added tests to cover the scenarios

Backwards-compatibility

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

No, though messages from the exception have changed

Documentation

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

No