The previous implementation of `PipelineStage#getDefaultNodeLabels`
caused a `groovy.lang.MissingPropertyException` as it was assuming a
previously implemented but since refactored structure for the `publish`
configuration.

Tests were added to cover `Pipeline#getRequiredNodeLabels` which
transitively covers `PipelineStage#getRequiredNodeLabels` and seemed
like a better "user" facing interface to test.

Change-Id: Iced37fe8ab4482f7931f91c3a0d6255cbeda68ba

Since the WMF docker registry only allows pushes from our internal
network, it makes more sense to always use the internal discovery name
when tagging/registering images, and the public name when qualifying
images for reporting, etc.

This should simplify the logic in downstream jobs that have previously
set the registry value based on where they will execute (which node and
its access).

Removed setting of docker registry from pipeline configuration as this
should not be a user-configurable value, but retained properties for
both public and internal registries so they may be overwritten by client
code.

Change-Id: If0567703257296a72edc3807ecb18fdc866c1078

Pipeline setup/teardown methods were referencing the wrong constants for
the internal stage names.

Added test coverage of `Pipeline#stack` which calls the offending
methods.

Change-Id: Iaec8fe56e382c57d8530d44cceb19b80c5fca5aa

Provides `PipelineBuilder` for reading `.pipeline/config.yaml` and
mapping user-defined pipelines, stages, and execution graphs to actual
Jenkins Pipeline stage definitions.

Provides `Pipeline` class that constructs a "stack" of `PipelineStage`
objects from the user-provided configs, each with its own `NodeContext`
for binding output values to names and consuming bound values from
previous stages.

Provides `PipelineStage` that contains core stage step implementations
based on the existing `service-pipeline` JJB job definition in
`integration/config`. A closure is returned by each stage for passing
off to Jenkins Pipeline stage definitions by the builder.

Steps have a fixed order within a given stage: build, run, publish,
deploy, exports. This allows for concise definition of a stage that
performs multiple steps, and deterministic behavior of default
configuration that references locally bound output values (e.g. the
default configuration of `image:` for an `publish: { type: image }`
publish entry is `${.imageID}`, referencing the image built in the
current stage's `build` step.) If the user needs to change ordering,
they can simply break the stage out into multiple stages.

See the `Pipeline` class for currently supported configuration. Note
that the aforementioned context system allows for user's to make use of
the same value bindings that step implementations use internally. They
can also use the `exports` configuration field to bind new values.

To illustrate the minimally required configuration, the following would
approximate the current `service-pipeline-test-and-publish` JJB job for
a project named "foo".

    pipelines:
      foo:
        directory: src/foo
        stages:
          - name: test           # builds/runs "test" variant
          - name: candidate
            build: production
            publish:
              image: true
            deploy:              # currently only the "ci" cluster
              chart: https://releases.wikimedia.org/charts/foo-0.0.1.tgz
              test: true

And to illustrate how the "candidate" stage in this example could be
expressed as multiple stages using references to the output names that
steps bind/export:

    pipelines:
      foo:
        directory: src/foo
        stages:
          - name: tested
          - name: built
            build: production
          - name: published
            publish:
              image:
                id: '${built.imageID}'
            exports:
              image: '${.imageFullName}:${.imageTag}'
          - name: staged
            deploy:
              image: '${published.image}'
              chart: https://releases.wikimedia.org/charts/foo-0.0.1.tgz
              test: true

Bug: T210267
Change-Id: I5a41d0d33ed7e9174db6178ab7921f5143296c75