Re-apply "Simplify Requests::Service::Receive""

This reverts the following revert commits:

* 12c10f029383314ba9da17a65f47f608633bd362
* 464f579c0f82edc47e451cd13b11551387d069ec
* b937d670c10669a702e08a2de3ab27d6be52ed4f
* 85edb5755d9c101f22142532c2d4d0e33562ffaf
* 12a0b1f216102e0c60360e7918fa3deaa0956406
* 6e3005e5d4bba56d86cd6e20b6a0072eca42681e
request receive: verify repository.owner

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 therefor 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 atm:

* Users include `owner_id` (our `id`) and `owner_type` in their API
  payload. In this case we can reliably look the according record up
  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 stategy is that users would have to
look our `id` up for the repository, and include it to their payloads.