PR fields and upgrade in archive

[MikeBishop]

Adds a few extra fields to PRs:

• baseRepository { nameWithOwner }
• baseRefName
• baseRefOid
• headRepository { nameWithOwner }
• headRefName
• headRefOid
• mergeCommit { oid }

Since it's the first time we've changed the query, it also creates a mechanism for upgrading old files to new versions.

The issue and PR retrieval are pulled into functions. These functions take a fragment with the fields that need to be fetched; the full run will get all fields, while upgrade passes in the fields that have changed. The functions are also more tolerant of things not being present on the returned object.

There's a dictionary of old versions and the fields that need to get changed to bring them up to a newer version. We could always bring them to the current version, or chain them, either way will work. After reading the file, if it's old, it calls the functions to fetch the newly-added fields on all the old objects.

I'm a little split on whether to include the upgrade or just indicate whether you need to dump the old objects and download fresh (i.e. this PR without the last two commits). You wind up visiting all the old objects anyway to get the new fields; having an upgrade path for the reference saves bandwidth on the retrieval and probably consumes ratelimit less quickly, but doesn't actually save any calls.

[MikeBishop]

The trouble with consistency is that we'd expect all changes to modify the output. If we take a stance that it's additive-only, we could check that everything the last version of master produces also appears in the newly-submitted version, perhaps?

[martinthomson]

Let's make the change then iterate.