FluxAddonClient: abstraction to encapsulate provider specific repository setup behavior.

We have decoupled git-specific actions from git-provider specific actions in the FluxAddonClient.

However, there are a set of actions that we take in the FluxAddonClient workflow that are dependent on wether or not we're using the generic Git 'provider' or a the Github 'provider' -- these conditionals are distracting and potentially prone to error. We should introduce a layer of abstraction which is separate from the FluxAddonClient workflow organization that hides these details.

One idea would be to turn what is currently the 'provider' into a 'repositoryManager', since it's strictly responsible for managing Git repositories, and re-introduce a new 'Provider' abstraction with a few basic methods -- such as

type Provider interface {
    BootstrapFlux() error
    Validate() error
}

which is responsible only for taking a git client, a git repository manager (currently the 'provider') and abstracting the BootstrapFlux calls so that their conditional logic can be removed from the FluxAddonClient workflow

Start at the FluxAddonClient workflow and trace the provider-specific conditionals and BootstrapFlux calls. Review the current provider's repository-management responsibilities, then determine where the proposed Provider interface and repository manager should be introduced. Done means provider-specific setup is hidden behind the abstraction and the FluxAddonClient workflow no longer contains those conditionals.