Separate Darc and PCS codeflow logic from VmrForwardFlower/VmrBackflower

[dkurepa]

Context

There are two ways to use the codeflow: through CLI and through PCS. For forward flow, we have a class called VmrForwardFlower that implements most of the flow logic. In the CLI scenario, we directly call into this class and preform what we need to.
In the PCS scenario, we have a class on top of this one PcsVmrForwardFlower that does some things of it's own, and then calls into the VmrForwardFlower. This inconsistency makes it a bit hard to read the code.
The same goes for the backwards flow

Goal

Make VmrForwardFlower and VmrBackwardFlower abstract, and add DarcForwardFlower/DarcBackwardFlower to be a class similar to the currently existing PcsVmrFlower classes

[adamzip]

There's considerable overhead in terms of debugging difficulty and code readability when introducing new abstract classes. Especially given that VmrForwardFlower and VmrBackFlower are themselves already implementations of the abstract class VmrCodeFlower.
If it's confusing that the PCS enters the code flower from PcsVmrForwardFlower and Darc does so from VmrForwardFlower, then how about getting rid of PcsVmrForwardFlower and having eveyone using VmrForwardFlower? In that case, we can have a couple of overloading methods that call the code flow based on the different arguments that Pcs and Darc are able to provide. There's not really a need for creating extra classes just for creating new entry points into the codeflow.

[dkurepa]

I think most of the things we wanted to do in this issue were covered in an previous PR. Both darc and PCS now have the same entry point in the VmrCodeFlower logic. Think it's safe to close