Async Reset Improvements

[mkorbel1]

Description & Motivation

There were a handful of bugs and issues related to asynchronous reset, reset values, simulator injections, waveform dumping, etc. This PR addresses a variety of those issues.

• Updated examples to be better and compatible with changes
• Improved InvalidReservedNameException messages
• Improved error messages when a port does not exist on an interface
• Added asyncReset to Sequential, FiniteStateMachine, Pipeline, FlipFlop, flop
• Make sequentials drive x if a trigger and non-trigger happen at the "same time" in a tick to help catch non-synthesizable behavior in designs around flops
• Fixed a bug where a multi-triggered Sequential may not generate X's if one trigger is valid and another (later specified) trigger is invalid.
• Added support for both posedge and negedge triggers on Sequentials
• Fixed and clarified resetValues behavior for Pipelines
• Fixed reset handling in Pipeline to use Sequential's automation instead of its own
• Change the Simulator so that it executes injected actions within main tick if possible.
• Yield execution for event loop before starting the simulation
• Added some error checking for vcd parsing in wavedumper tests (not API visible, just for dev)

It also encompasses and supersedes #483

Adds support for negative edge-triggered Sequentials. In some cases, downstream tools may treat an inverted clock fed into a sequential differently than a negative edge triggered sequential. Functionally, in simulation, the behavior is the same for either option. Generators may choose to generate these differently (e.g. using negedge vs. posedge in SystemVerilog generation).

Additionally fixed a bug where a multi-triggered Sequential may not generate X's if one trigger is valid and another (later specified) trigger is invalid.

The changes also motivated some refactoring of trigger handling in Sequential, as well as renaming of the first positional argument in Sequential.multi.

Related Issue(s)

Fix #531
Fix #528
Fix #338
Supersedes #483

Testing

Added extensive testing for applicable areas

Backwards-compatibility

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

Yes!

• Breaking: injected actions in the Simulator can now occur in either the mainTick or clkStable phases. This API will generally continue to work as expected and as it always has, but in some scenarios could slightly change the behavior of existing testbenches.
• Breaking: Simulator.run now yields execution of the Dart event loop prior to beginning the simulation. This makes actions taken before starting the simulation more predictable, but may slightly change behavior in existing testbenches that relied on a potential delay.

Documentation

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

Generally no, but API docs were updated. This is mostly fixing behavior, not adding/changing.