Add support for local filesystem aliases of remote URLs

[BradNicolle]

Currently, to run test configurations which reference external GitHub URLs, we must provide a Personal Access Token (PAT) to the uss_qualifier. This presents some overhead in creating, configuring, storing, and refreshing this sensitive value. It also presents opportunities for human error, including misconfiguration of scopes, storage/accidental leaking of the sensitive value, and typos in the environment variable config.

Proposed solution
Another approach could be to allow the uss_qualifier to be configured with aliases for GitHub repos, akin to Golang's replace directive in go.mod.

Specified via CLI arguments or env vars, any reference to e.g. github.com/foo/bar could be replaced with a local file path e.g. /repos/foo/bar. The uss_qualifier would then locally resolve any reference to the remote URL it encounters in the test configuration, potentially building an entire dependency graph using offline files.

This delegates responsibility of access/cloning those repos to the environment in which the uss_qualifier runs. For example, Google Cloud Build natively supports mounting GitHub repos to filesystem paths.

If this configuration is not set, the uss_qualifier could keep its existing behaviour of attempting to fetch directly from GitHub using a PAT (or any other remote URL). Thus, this would require no modifications to configuration files which reference remote URLs directly. These could also continue to work in environments where the PAT is more appropriate, or even combinations of locally-aliased and remote files within the same config.

Alternatives
GitHub also provides the concept of "Deploy Keys", which are just SSH keys that can be granted read (or read-write) access to a repo.

As an SSH key, only the public key needs to be shared and exposed to users for configuration e.g. when pasting into the GitHub UI. Currently, human users need to convey the sensitive PAT from GitHub through to the uss_qualifier hosting configuration, which allows multiple chances for exposure and misconfiguration.

The private key can be kept secure, and even kept isolated from the uss_qualifier executable (e.g. if the uss_qualifier delegates to an SSH client installed within the container).

If the private key is kept sufficiently secure, key rotation can be avoided, reducing toil compared to an expiring PAT.

The "local filesystem alias" approach is preferred as it is more general (any type of private repo could be supported, not just GitHub) and should be simpler to implement and configure.