Roles for our pathogen-repo-build GitHub Actions workflow, take 2

[tsibley]

GitHub OIDC → Cognito Identity → AssumeRoleWithWebSession

Let's us map GitHub token claims to principal tags, which is great. No need to customize the "sub" claim any more, and granular matching.

But ultimately not workable because GitHub OIDC doesn't include the repository name sans owner in its token claims (e.g. "zika" for "nextstrain/zika"), so we don't have any policy variable to interpolate into policy conditions.

I thought maybe we could (ab)use role session names for this and pass the unqualified repo name via it ourselves, but that hit a wall because while sts:RoleSessionName is available in the AssumeRoleWithWebIdentity request, it's not available on subsequent requests which we need to be able to use in policy conditions.

Then I thought maybe we could use sts:SourceIdentity instead in the role assumption request which is available as aws:SourceIdentity in subsequent requests, except that GitHub's token would have to include an "https://aws.amazonaws.com/source_identity" claim, and it ofc does not provide any way to do that. If it did, it would likely also let us provide a custom "https://aws.amazonaws.com/tags" claim at which point all of this nonsense would be moot anyway.

Finally, I thought maybe we could use a custom audience ("aud" claim) which GitHub does let you specify. This is available in AWS requests as the "token.actions.githubusercontent.com:aud" key and we can use it as a policy variable. \o/ But to use it we'd need to cut out Cognito Identity (e.g. go back to where we started without it) and lose the token claims → principal tags mapping. So we'd need to customize the GitHub token's "sub" claim and match against it. We'd also need to explicitly list out all possible valid "aud" on the AWS OIDC IdP configuration (as "client_id_list"), and that would be frustrating.

This all feels more complex than it's worth at this point.

Resolves: #4
Related-to: nextstrain/.github#81
Related-to: #6