Review and refactor interaction with Github repos

[davemcorwin]

1. On site creation

• create a read-only deploy key in the repo
• set the user's access token as THE access token for the site

2. Use the new deploy key when cloning the repo in the build
3. Use THE access token when interacting with the Github API
4. On site destruction, remove deploy key and webhook

Once this is done, we can backfill the repo token by finding an admin for each repo and using their access token.

We should also review the scopes we currently ask for to ensure we are using the minimum ones.

Context: Federalist is an OAuth application which means that everything that it does is on behalf of a particular user. Once a user has granted Federalist permissions to interact with the platform on their behalf, the access token we receive is permanent until the user revokes it. In addition, if we choose, we can maintain different access tokens that correspond to different scopes. For example, the scopes required to create/remove a site on Federailst are different than those required to just view a site.

By setting one access token as THE token for a site, to be used when creating commit statuses and removing a site, AND using a deploy key when cloning the repo, we can remove the need to "find an access token" to do things on Github.

[davemcorwin]

cc @apburnes @amirbey

[davemcorwin]

We also have to address what happens if the user who's access token token is used loses access to the repo or federalist. I think it's fairly straightforward to check and update this as users authenticate, however, if the access token becomes invalid, status reporting will fail and we need a way to notify the repo users/owners.