Better tester concurrency specifications?

[ducky64]

Currently, we have these tester interfaces:

• Circuit tester, included in chisel3. Synthesizable (this feature isn't often used, if at all), lightweight, but not great for writing anything even moderately complex.
• Peek-poke tester, where the user specifies a testvector across time. Easy to write testvectors that are temporally linear.
• Advanced tester, which is a mix of "background" processing elements (used to implement Decoupled sinks / sources) and "foreground" LTL-inspired constructs (until, eventually).

So overall, it seems to be a difficult task to write testvectors that are are not temporally linear (for example, if you have multiple things going on at once, but it would be overly burdensome to manually interleave it in a testvector) - the special case exception being Decoupled operations in AdvTester where cycle-by-cycle timing behavior is inconsequential. AdvTester provides a framework for general parallel testers, though it's not particularly easy to specify (need to think about what happens on every cycle, instead of independent sequences as a while).

So, ideas for better nonlinear test specification? Some ideas might be:

• Threading-like architecture, where there are multiple independent threads of control.
• Parallel LTL, essentially where you can create futures at any point in the foreground and have those futures running in the background
• Is it worth keeping the 3-phase execution we have in Advanced Tester (split between preprocess, postprocess, and user step? What are other options for preventing intra-cycle timing issues between different processes?

[edwardcwang]

Related to new tester work in #551 but is a somewhat orthogonal issue.

[ducky64]

Superseded by #725.