Revisit what `FlowForwardAsync` and `FlowBackwardAsync` return

[dkurepa]

Context

Currently, the two main methods responsable for flowing code VmrForwardFlower.FlowForwardAsync and VmrBackflower.FlowBackAsync both return a CodeFlowResult that has shas from the previous flow (for both VMR and the product repo). We're returning these so we can generate a URI between the two diffs, the one we started with, and the one we just flew.

This might not be the best design, and maybe we should revisit it. It might be possible to get this commit sha in some other way, and not return it from the CodeFlowers

Goal

Explore if there's a better way of passing the "start" sha to PullRequestBuilder

[premun]

I think this might be handled with #4407 as that will touch this area too

[adamzip]

In the current way we look up the previous codeflow as part of the new codeflow, and we include it in the result. The only alternative to that I see is that we would have a separate method for looking up previous codeflows, and then we would have a codeflow method that is made more generic because it would to take the previous SHA's as arguments, and it would have to blindly assume that those are the correct SHAs that represent the last flow. I think the second approach is much worse - it is better for many reasons to give the responsibility of finding the previous codeflow to the method that runs the new codeflow. Plus, this would essentially mean we are moving some codeflow logic to the PullRequestUpdater, that will now have the responsibility to orchestrate the previous point to flow code from.

[premun]

I think it's alright to keep it as-is. I think this issue might as easy as just using the CodeFlow type to convey the previous flow, name it appropriately and maybe adding the current flow there too. But I think just having the CodeFlow previousFlow is good enough?