More alternatives to workflow authorization

[jku]

Currently tuf-on-ci supports either the default token or a Fine-grained personal access token (in secrets). Neither of these is great since the token does needs some extensive permissions.

There's an issue in sigstore/root-signing-staging#98 about using an App token instead. Among the options there is one possible tuf-on-ci feature which I'll document here.

We could support specific application tokens in our actions:

• Our composite actions use actions/create-github-app-token or octo-sts/action to produce a short lived token (when configured to do so)
• the later steps in the composite action then use one of [short lived token, secrets.TUF_ON_CI_TOKEN, secrets.GITHUB_TOKEN]

Some questions:

• Do we really want to make decisions on what "token apps" we support (the alternative is to leave the complexity to the workflow user -- the y can always modify the workflow so the token is whatever they want: this leads to workflows that are difficult to keep updated from tuf-on-ci-template but maybe that is ok at this point?)
• How would this be configured? We could say secrets.TUF_ON_CI_TOKEN or another variable can contain magic values that decide which token source is used -- we could also say e.g. that if the octo-sts config files are in place in git, they get used. This feels a little too magical