Overhaul of Driver + Monitor for Avalon-ST interface (w/ and w/o packets)

I use cocotb extensively at work, and have expanded on the classes AvalonST(BusMonitor), AvalonSTPkts(BusMonitor), AvalonST(ValidatedBusDriver), and AvalonSTPkts(ValidatedBusDriver) to (almost!) fully implement and update the parameterizability of the Avalon-ST interface for use with our internal TBs. The most recent spec is here (see ch 5); the current cocotb implementation is outdated. For the sake of being explicit, refer to Table 18–I’ll be adding the logic associated with every property other than associatedClock, associatedReset, and beatsPerCycle for both packetized and non-packetized Avalon-ST interfaces. I will open a PR here once things are complete on my end 😃

JSYK, I’m making use of the transitions package to represent each interface as an FSM–I hope adding this dependency is no issue!

In reference to issue #864, I hope that this motivates a decision to retain the Avalon interface modules as core functionality–it really makes cocotb that much more accessible!

[bluecmd]

@nredd Just a voice of support from me, an internet stranger. The Avalon drivers of cocotb are great and saves me so much headache and time. Improving them would be wonderful.

A positive thing about splitting to extensions is that that potentially means you can use extra libraries in those extensions, as it wouldn’t polute the core framework. I’m not a maintainer, but if you’d still like to use your transitions library it might be an easier sell if it’s an optional add-on to cocotb.

[eric-wieser]

@nredd: I think the easiest thing for now would be for you to make nredd/cocotbext-interfaces or whatever you deem best (https://github.com/nredd/cocotbext-interfaces) - and then when we get around to it, we can pull a bunch of repos under the cocotb namespace all at once, and merge / split them as makes sense.

We can add a link to nredd/cocotbext-interfaces from our wiki page which lists extensions