Further to the move - the VirtualBranchesExt trait creates a dependency towards gitbutler-project. The gitubler-branch crate doesn't have such dependency so i deemed it undesirable to introduce it just for a convinience method.
(Separately added an extention in gitbutler-virtual-actions since it already depends on project and to create a smaller diff)
This is more descriptive to what logic lives inside. Further, this allows for splitting up the just branch bits in a separate crate (which is currently in gitbutler-core)
This type currently acts more or less like a command context that lives for the duration of the request. Regardless of if we wanna keep this pattern or not, separating it out helps us split up core
This protects us from cyclic dependencies. Unfortunatelly as part of this, i had to introduce the imp Project as trait implementations since now Project is foreign
We want to move towards having each functional domain in a separate crate.
The main benefit of that for our project is that this will enforce a unidirectional dependency graph (i.e. no cycles).
Starting off with virutal_branches - a lot of the implementation is still in core (i.e. virtual.rs), that will be moved in a separate PR.
Furthermore, the virtual branches controller (as well as virtual.rs) contain functions not directly related to branches (e.g. commit reordering etc). That will be furthe separate in a crate.
