Investigage `Drivable` implementation for `Wishbone`

[lmbollen]

Currently there is no nice way to actually test Wishbone circuits because their bidirectional nature does not work well with the current Drivable typeclass. We should investigate if there is a nice way to specify requests and response that matches the current Drivable typeclass.

A crude example of this could be implementing a data type similar to https://github.com/bittide/bittide-hardware/blob/staging/bittide/tests/Tests/Shared.hs#L57-L66 :

-- | Single datatype to represent successful and unsuccessful Wishbone transactions.
data Transaction addrW selWidth a
  = WriteSuccess (WishboneM2S addrW selWidth a) (WishboneS2M a)
  | ReadSuccess (WishboneM2S addrW selWidth a) (WishboneS2M a)
  | Error (WishboneM2S addrW selWidth a)
  | Retry (WishboneM2S addrW selWidth a)
  | Stall (WishboneM2S addrW selWidth a)
  | Ignored (WishboneM2S addrW selWidth a)
  | Illegal (WishboneM2S addrW selWidth a) (WishboneS2M a)
  deriving (Generic)

And a function:

wishboneMonitor :: forall dom addrW selWidth a .
 Circuit (Wishbone dom mode addrW a) () ->
 Circuit () (Wishbone dom mode addrW a) ->
 Circuit () (Df dom (Transaction addrW selWidth a))

That allows you to provide a master and slave to create a circuit that produces the transactions.
Instead of the custom Transaction it could also be simply ((WishboneM2S addrW selWidth a), (WishboneS2M a)) accompanied by utility functions.

It is very much still unclear what the best way to approach this is so feel free to discuss / experiment.
Ideally the solution would be accompanied by a way to imperatively construct "programs" consisting of sequences of requests.