Sf register services

On the quest of eventually splitting up travis-core.

This currently includes:

* abstracting the services api further by registering service classes
  explicitly so that clients do not have to depend on the service class
  hierarchie

* flattening the namespaces for service classes so they (mostly) still map
  to the names they're registered with (e.g. `:find_builds` maps to
  `Services::FindBuilds` instead of `Services::Builds::FindAll`)

* moving services that are related to aspects other than core domain models
  (such as github) or aspects that are run by small apps (such as enqueue,
  logs) into separate directories so that they can be moved over soon

* adding additional service classes for where travis-hub and travis-logs
  amqp handlers were still accessing models directly (e.g. worker status
  updates, log updates)

After doing this work I believe that I have a pretty clear picture of how
the eventual architecture can look like in terms of splitting travis-core
up into smaller repos.

Here's what I imagine:

* All logic relevant to a given request incoming from the api, amqp or
  sidekiq should be in service classes so that they can be easily plugged
  into a different receiver.

* "Handlers" for amqp, sidekiq and whatever other messaging/queueing tech
   we might choose in future should contain nothing else but logic that
   is required to turn the incoming message into whatever the service
   class expects.

* Services that now sit in travis-core but are relevant to a certain
  deployable app (travis-enqueue, travis-logs, travis-gatekeeper etc)
  should be moved to these apps/repos but kept in a way so they are also
  loadable from other apps (e.g. travis-hub)

This will give us:

* The ability to still move responsibility for running certain aspects
  around (e.g. handling logs in travis-hub vs travis-logs) by switching a
  feature flip with minimal extra code/bugs/complexity.

* A much leaner travis-core repository that can be stripped down to mostly
  just core model classes (which in future should also be slimmed down further)

* Much faster development cycles because we don't have to deploy up to 10 apps
  for testing a few changes in travis-core any more (since that has been broken
  up)

Examples:

Stuff from travis-core/lib/travis/enqueue can go to the travis-enqueue repo,
stuff from travis/logs to travis-logs, travis/requests to travis-gatekeeper,
travis/github to a new repo travis-github.

More future refactorings that I plan to do:

* Move travis/addons and travis/mailer to travis-tasks

* Turn travis/api into travis/serializers, make it pluggable just like
  addons and services, then split it up and move serializers to their
  respective client libs. E.g. http api serializers can go to the travis-api
  repo, task/addon serializers to travis-tasks etc.

* Possibly move travis/notifications and travis/features to travis-support

Ideally we'd eventually be able to run any "aspect" like "process log updates"
or "process incoming requests" on any small app, picking messages up from any
queue/tech we want. This obviously would require more work on the handler 
integration side and we might not need to go into that, but knowing that only
very little extra work would be required seems like a good indication to me
that this "big picture" is moving into the right direction.