Users can impersonate Shipit on github using the GITHUB_TOKEN env var

GITHUB_TOKEN is provided in the environment to authenticate git clones. However as it remains in the environment after the initial clone, users can consume this token in their own scripts to impersonate Shipit on Github through the API. This is not ideal because:

• The token is only designed to be valid at the start of a task to facilitate git cloning (can potentially only be valid for 10 minutes) - if people are relying on it later on in a longer task, it will break unexpectedly from their point of view
• The unexpected use of the token by users creates an unreliable 'feature' from their perspective
• Shipit is already a highly privileged entity - lots of access to Github and lots of credentials for production - allowing custom code to impersonate Shipit makes reasoning about its access even harder. We want to be limiting Shipit's access where possible, letting people hit the API on their own means we're likely to break something without realising it

I consider this a bug and would like to fix it. Some options:

• Can we limit the access of the token itself to only repo read(/write?)?
• Can we only set the variable for git commands?
• Obfuscation: move the token into a file or expose it via an endpoint
• Consider unsetting the variable after the git clone has finished. One big issue with that I see is it would break any user supplied git commands at the start of a task - e.g. fetching tags/submodules.

Start by reading lib/shipit/commands.rb at the GITHUB_TOKEN setup and lib/snippets/git-askpass to understand how the token reaches git clones. Define completion as preserving the required clone authentication while preventing user-supplied task scripts from using the token to impersonate Shipit, and add or update coverage for that behavior.