feat(replace-release): Allow platform providers to replace a release in a local product file

[crhntr]

This new command would allow platform providers to work with support to surgically replace a single bosh release in a tile.

I would especially appreciate edits/review of command/flag names and descriptions.

GIVEN a platform provider downloads a BOSH release
AND a platform provider downloads a product tile
WHEN the platform provider runs
  om unsafe--replace-release \
    --product 1.0.0.pivotal \
    --product-output 1.0.1-fix.1.pivotal \
    --new-product-version 1.0.1-fix.1 \
    --existing-bosh-release banana/7.8 \
    --new-bosh-release banana-7.9.tgz
THEN the platform provider gets a deployable tile with the new release

To Do

• Fix/improve command/flag names
• Add some happy path assertions on the metadata and files
• Add some failure case assertions
• Consider if we should do some Semver checks to ensure a platform provider does not input a GA tile version (see the second note)
• Consider the config coming from a yaml document (instead of flags) to allow for patching multiple releases (this would be helpful if a CVE exists in a BOSH release vendored into multiple releases)
• Create a knowledge base article template for incident response (this might live in an internal repo)
• Shepard this PR through Platform Automation CI

Notes

• This change bumps the yaml library from v3 to v3.0.1. We use yaml/v2 everywhere else. The v2 version line is a different module so this bump does not affect other yaml parsing.

• This change as is does not yet ensure the new tile version is not going to be problematic.
  We may want to have the tool fail if the "new-product-version" is not a pre-release of the next patch. For example, "1.0.4" would fail but "1.0.4-banana" would succeed.

• This implementation only allows one release to be swapped. If we need to swap multiple releases, this could be cumbersome. I imagine some sort of patch file could be a better interface because it would allow us to make more product changes in a single operation and provide better integration with Platform Automation.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[ameowlia]

This doesn't do the bosh deploy does it? Either way, I suggest calling it out what other steps you need to do to get to the desired end state.