Implement git.FilesystemStore

[GeorgeMac]

The purpose of this issue is to track the core Git implementation of the api.FilesystemStore interface. This type handles obtaining a mountable implementation of the wazero filesystem abstraction.

While we have a fs.FS compatible implementation, we will start out with using their DirFS implementation which goes straight to the underlying host filesystem. Eventually, we may move to a virtual implementation when they make their internal interface public.

We will leverage go-git and explore supporting both in memory and on disk (/tmp) clones. We need to support both reads and writes.

Reads should be in the form of a read-only snapshot of a given revision. The write interface should be transactional and isolated.

Configuration

As with the local implementation, we should support a source type: git in configuration with relevant fields.

sources:
    flipt:
        type: git
        git:
            repository: https://github.com/flipt-io/flipt.git
    cup:
        type: git
        git:
            repository: https://github.com/flipt-io/cup.git

View

View requires the product of a simpler, read-only snapshot of the filesystem for a target revision.

The revision supplied could be a target SHA or a reference that needs resolving to the latest available SHA.

Once the provided function to View has returned, the implementation simply needs to propagate any error values forward.

Update

Update is more complicated than View. In particular it handles the update flow documented in the design document here: https://github.com/flipt-io/cup/blob/main/docs/DESIGN.md#flow.

This implementation is the heart of the contribution flow inside cup. At a high-level for each Update it must at-least:

1. Resolve the requested source configuration
2. Checkout a new branch for the contribution
3. Create a blank worktree for the target revision
4. Build a controller.FSConfig to mount the new worktree
5. Invoke the provided function with the FSConfig
6. Add any changes to the worktree, commit and push them to the target upstream
7. Open a pull-request on the configured source target SCM