Wrap requests in an ApplicationContext

This provides context to all requests made to Rails controllers or
grape endpoints.

Doing this starts a new `Labkit::Context`, to which we can provide a
namespace, project and user.

We're currently setting the following values:

- Web requests: In the ApplicationController we wrap the entire
  request in a `with_context`.
  - user: based on the `auth_user` if there is one
  - project: We try to read the @project instance variable of the
    controller.
  - namespace: We try to read the @group instance variable of the
    controller. If there was none, but the project was set, we'll use
    that path to set the namespace

- API requests: The application context is pushed in a before block
  setting the following values:
  - user: to `current_user` if there is one
  - project: to `@project`
  - namespace: to `@group`

- Internal API requests: the application context is pushed in a before
  block:
  - user: When to the user set in `Api::Support::GitAccessActor`
  - project: to @project if it was available

The 3 supported attributes for a context are read lazily when
required.

This also replaces the existing correlation middlewares with the new
Labkit::Context middlewares.

The rack middleware wraps each rack request in an overarching context
that adds the correlation id. The context is cleaned up after the
request, so we're sure all child contexts are cleaned up as well.

The sidekiq client middleware will write the context into the job that
 goes into redis when a job is scheduled.

The sidekiq server middleware will then re-instantiate this context so
the job gets executed with the same context that was alive when it was
scheduled. This means that any new job scheduled from sidekiq would
also have this context.