Allow different levels of Github OAuth access

[ara4n]

We should give the option of what level of githubbery we'll let NEB do. From an infosec perspective some folks will be rightly very skeptical about giving a 3rd party bot any kind of access to their private GH repos

[kegsay]

Github are particularly annoying with that because they are way too broadly scoped OAuth scopes - it's either public_repo (FULL r/w access), private_repo (FULL r/w access), and so on. In reality, we only really want read access :/ but alas.

There are 3 kinds of "levels of githubbery" I think will be appropriate:

• Minimal access. Required to create issues. Starter links should request this level of permissions.
• Public repos. Make the "Login with OAuth" button only request public repos scope (+webhooks). Will show only public repos on the webhook ticky box list.
• Public and Private repos. Make an additional "Login with OAuth (incl. private)" button which does everything (like we're doing now).

In practice, this means /requestAuthSession needs an additional parameter to say what level of auth you want to do on Github. If the level of auth is missing, then it'll do the minimal set (this is important because starter links have 0 args because Vector doesn't know how to interact with integrations). This parameter will be set depending on which of the 2 "Login with OAuth" buttons you click. This also requires a tweak to /getSession, as it will proudly proclaim you have authenticated when really it is the minimal set of things and you can't do webhooks. We'll need to check for failures due to lack of permissions (which are now recoverable failures) as well.

[wezm]

It appears that more fine grained access to private repositories is available though the GitHub Apps API. When done this way the app is "installed" into each private repo it should have access to and the permissions can be more fine grained. This is the approach the Slack integration takes.