Properly sets the build status for the non-exceptional code path when
teardown is reached, and fixes the conditional for finding the teardown
stage in the exceptional code path.

Change-Id: I61e01b6920488a330af59ead141842430572876c

The configure stage previously depended on the `scm` job property being
available. This is only available, however, for jobs that source a
`Jenkinsfile` from the repo, not the pipeline scripts sourced from
`integration/config` groovy files.

Calling `PipelineBuilder#build` in the context of the latter results in
the following error:

> ERROR: 'checkout scm' is only available when using "Multibranch
> Pipeline" or "Pipeline script from SCM"

The builder needs to support being called from both a `Jenkinsfile` and
the scripts defined in integration/config.

Change-Id: I1dae576c35c4ea1a8746ec418290c52679314598

The "configure" stage needs somewhere to execute and the "blubber" nodes
seem like reasonable choices.

Change-Id: I81a50fad6c6dace77a72c6eef6cfe343968675be

Adds a `pipelineName` argument to `PipelineBuilder#build` that can be
used to restrict execution to a single pipeline defined in
`.pipeline/config.yaml`. This should allow for greater flexibility in
upstream gating systems like Zuul. For example, different pipelines can
be triggered for test vs gate-and-submit events, etc.

Change-Id: I47937d6a2354204ca81cf602815e04465749d34b

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