Reconsider git clone fallback

[phillebaba]

Describe what should be investigated or refactored

When git cloning fails using go-git we will fall back to use the git CLI instead. Withing Zarf we should strive to reduce the amount of shelling out that is done within the code. Relying on external binaries comes with its own set of challenges and security considerations that should a much as possible be avoided. To start off we should define the reasons the fallback exists and create tests to validate when the fallback works as expected.

Links to any relevant code

https://github.com/zarf-dev/zarf/blob/81f1c7085ea954fd0d8e1610bc516d2b342965e8/src/internal/packager/git/clone.go#L78-L126

Additional context

A lot has happened in the go-git project since the fallback was introduced, a lot thanks to the work of the Flux maintainers. This has for example resolved any challenges with cloning from Azure DevOps or AWS CodeCommit. Flux has since removed libgit2 as a dependency and only relies on go-git for its functionality. Considering that they are able to rely completely on the project I have a feeling that we should also be able to.