This changes used worker from `BuildProcessWorker`
to `PipelineProcessWorker` to make pipeline
processing much simpler. We process `pipeline_id`,
based on some triggers.

Currently, some of the jobs with `needs:`
would be processed in stages, it means
that `when:` for such jobs would not be
respected.

This changes the behavior to have a separate
execution paths for jobs with `needs:`.

This implements the support for `needs:` keyword
as part of GitLab CI. That makes some of the jobs
to be run out of order.

Prepares us for upgrade to Rails 5.2

Introduces the concept of Prerequisites for a CI build.
If a build has unmet prerequisites it will go through the
:preparing state before being made available to a runner.

There are no actual prerequisites yet, so current
behaviour is unchanged.

Introduces a new status for builds between :created and :pending
that will be used when builds require one or more prerequisite
actions to be completed before being picked up by a runner
(such as creating Kubernetes resources before deploying).

The existing :created > :pending transition is unchanged, so
only builds that require preparation will use the :preparing
status.

In a few models we define ActiveRecord enums that are redefined in EE
using the following pattern:

    enum :some_enum, {
      ...
    }.merge(EE_ENUM_VALUES)

This particular approach is problematic to deal with, because it
requires that we `prepend` and EE module _before_ defining the enum.
This typically translates to the `prepend` being the first line in the
model in EE, but this can easily lead to merge conflicts when developers
add more `include` and/or `prepend` lines.

As part of https://gitlab.com/gitlab-org/gitlab-ee/issues/8244 and
https://gitlab.com/gitlab-org/gitlab-ee/issues/8241 we are moving
`prepend` to the last line in a file, reducing the chances of running
into merge conflicts. This poses a bit of a problem with the pattern
above, because this pattern does not allow us to move the `prepend`
further down a file.

To resolve this problem, we simply move the Hash value of the enum to a
separate class method. This method is defined in a separate module where
necessary, allowing us to use it like so:

    enum :failure_reasons, ::SomeModelEnums.failure_reasons

The method in turn is defined in a very straightforward manner:

    module SomeModelEnums
      def self.failure_reasons
        {
          ...
        }
      end
    end

This makes it easy for EE to add values without requiring the `prepend`
to be placed before the `enum` is defined.

For more information, see the following issues and merge requests:

* https://gitlab.com/gitlab-org/gitlab-ee/issues/8244
* https://gitlab.com/gitlab-org/gitlab-ee/issues/8241
* https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8424

The soft-archived builds cannot be run after some deadline time.
The intent is to aggressively recycle old builds after sometime.