Promote lifecycle and pack binaries rather than rebuilding them in CI

[thisisnotashwin]

For both pack and lifecycle binaries, each release candidate should be shippable as a release, just by renaming the final generated artifact (no re-compiling, unzipping, etc.)

Tasks:

• [x] Promote lifecycle images
• [x] Promote pack binary (update version ~& lifecycle tag~)
• [x] Fix semver resource flow for pack to bump after release, not before (and update lifecycle semver resources too)

---

Considerations for pack:

When pack is built, we need to assign a version number equivalent to the to-be-released version (e.g. 1.2.3 and not 1.2.3-build.4)

When pack is built, we bake in an initial builder image location. Rather than building pack twice (pointing to an RC builder for acceptance testing, then a released builder for releasing), we can just build pack once before acceptance, specifying the assumed location of the released builder. Then we can use the PACK_TAG env var when running acceptance to keep the tests using the release candidate builder. We should also assign PACK_PATH when running acceptance, to keep the tests from building its own pack executable.

Considerations for lifecycle:

Images built before acceptance can be promoted (i.e. retagged), but the run image reference in the samples builder must be updated upon releasing.

[ameyer-pivotal]

@matthewmcnew and I decided to track baking a lifecycle tag into pack as a separate story. There are complications with doing it now as we need to solidify a migration strategy for pack configs that currently reference v3alpha2.

Will update comment later with link to that story.