Request receive: verify repo owner

(Disregard the first commit. The first commit is a sqashed version of commits from a previous pull request which we merged and had to be reverted. All actual changes for this current pull request are in https://github.com/travis-ci/travis-core/commit/bbe2db2080db1b91cd1e0f5817469d43f75b9b9f)

We set the repository owner during user sync, but at build request
reception time the repository owner may have changed. E.g.:

* create a repository user/repo
* sync account, and hook up the repo
* transfer the repo to an org (this makes it org/repo, but keeps the
  `github_id`)
* trigger a build before the next user sync has run for any user
  on this org

It seems this case can happen quite frequently. We therefore verify
the repository owner against the incoming data. If the owners do
not match then, we update the repository owner. We *do* require that
this owner exists on our side though, and do not create new user
or org records on the fly (as we used to do).

For push and pull-request events coming from GitHub we can always use
the `owner_id` (`github_id`) and `owner_type` attributes to identify the
current owner record.

For API requests two strategies work at the moment:

* Users include `owner_id` (our `id`) and `owner_type` in their API
  payload. In this case we can reliably look up the record and update the owner.
* Users only include `owner_name` and `name` in their API payload.
  In this case we look the record up by `owner_name` and another edge
  case might kick in: Should the same owner have been deleted on GitHub,
  snagged by another person, and things have not been synced yet, then
  the repository might be assigned to the wrong owner (which was deleted
  on GitHub).

This second strategy makes the API endpoint easier to use, since users
only need to know the `owner/name` slug of the repository (which is used
in a lot of places). It also introduces an edge case though, and I am
leaning towards removing this.

The downside of removing this second strategy is that users would have to
look our `id` up for the repository, and include it to their payloads.