Add GitHub Actions CI integration

[chrahunt]

Using nox, pytest, and GitHub actions.

[chrahunt]

See run here.

[webknjaz]

#23 / #18

[chrahunt]

Thanks!

To justify this change in the context of the comments brought up previously (you know this better than me, but for others reading):

1. Since GitHub actions supports cron out of the box, we can hook it in very easily to do e.g. a nightly test against pip master
2. GitHub actions supports Windows, Linux, and macOS out of the box, so there's much less complexity - no need to get org admins to set anything up with third-party CI providers

I also wanted to pick up #31 but felt it would be hard to do confidently without an easy way to test that it works outside of "my machine", so this seems like a prereq to me.

[pfmoore]

Sorry, I'm not at all familiar with whatever this is (Github workflows?) I'd rather someone else reviewed it. But if there isn't already, adding a pointer in our developer docs to the github workflows documentation, to allow people to find out about how this works, would probably be useful...

[webknjaz]

@pfmoore it's a new built-in CI/CD that GitHub itself now provides. https://github.com/features/actions/signup

[pfmoore]

Thanks. I'm still not a good person to review (and don't have much time at the moment anyway) but what's the benefit of using this over Travis and Azure which we already use? Do we need another CI? Is it a good idea to tie ourselves more closely to Github? Diversity seems like a good thing to me (I'm thinking of Bitbucket dropping Mercurial support here...)

[webknjaz]

@pfmoore GitHub Actions are more performant and allow up to 20 parallel jobs. And there's a number of other benefits. Talking about vendor-lock, I wouldn't call it that. After all, we're running some commands in some CI, it's fairly easy to migrate the same commands to run in another CI. This one just happens to be better integrated with GH, shows results right in GitHub's UI and allows reusing sharable components which is quite handy.

[webknjaz]

Oh, and this specific repo doesn't have any CI connected. There's been several PRs but nobody seemed to agree that it's needed.

[pradyunsg]

I'm OK to merge this as is. I feel like the configuration could use some polishing but I'm happy to merge this in eagerly and iterate on this as we go.

[pfmoore]

Whoa, sorry - I completely missed that this was get-pip not pip (both sets of notifications sort into the same folder for me). My apologies.

In that case, I guess I have no problem with picking github for the CI for this project. You can also ignore my comment about a pointer in the docs, which isn't relevant here.