`nextstrain run`: third-party pathogen repo support

[victorlin]

continuing discussions from #444 (comment)

Better support nextstrain setup and nextstrain run for third-party repositories, including private ones.

Two avenues to consider for such support.

1. Indirectly with local support, i.e. workflow users git clone the private repo and point nextstrain setup/run to the local path. The downside here is the need to interact with git.
2. "better UX" of nextstrain setup/run my-org/my-pathogen (listed in Workflows as programs public#1) or similar

Both approaches require some form of authentication to download the repo contents, which inevitably requires some external interaction with the repo host. For repos hosted on GitHub, gh auth login simplifies the process.

[tsibley]

Reviewing this again today, I'm leaning towards something like

nextstrain setup my-pathogen@version=https://github.com/my-org/my-pathogen
nextstrain setup my-pathogen=https://github.com/my-org/my-pathogen

# maybe even…?
nextstrain setup https://github.com/my-org/my-pathogen

and special-casing such URLs so we handle them like our repos (i.e. knowing we can interact with them via the GitHub API (well, via nextstrain.org) and not fetching the source from the given URL directly).

Benefits of this approach:

1. Provides GitHub preferential treatment (i.e. ease of use), but without excluding preferential treatment for other sources/providers in the future (i.e. like my-org/my-pathogen@version would do).
2. The URL itself provides a convenient place to specify hard-coded credentials if desired, e.g. https://user:api_key@github.com/my-org/my-pathogen. We would adjust nextstrain version --pathogens --verbose output to mask the secret part of the URL.
3. It allows for colocating versions of a forked pathogen repo under the same name, e.g. name@nextstrain-version and name@your-version=https://github.com/your/repo (unlike your/repo@your-version).

I considered the alternative of namespacing, e.g. something like

nextstrain setup github:your/repo

but I think inventing up prefixes/URLs like that is less clear than using common URLs already out there that people can see in their browser. (There's precedent for this approach in nextstrain remote too.)