Mutable Deployment Support

[mitchellh]

Is your feature request related to a problem? Please describe.
Waypoint has an opinionated workflow: build, deploy, release. This opinionated workflow is what enables us (or will enable us) to build features such as per-deploy URLs, promotion, canaries, etc.

The downside of the opinionated workflow is that it doesn't work very well with pre-existing deployment tooling that a user may have already setup. Users can't just bring their existing Nomad jobfiles, Kubernetes YAML, or other setups because most of these tools follow a pattern of updating existing resources vs. Waypoint's repave model.

This significantly increases the burden of adopting Waypoint because users who want to "just try" Waypoint are forced to rethink how their deployment works. Additionally, at Waypoint's early age, it is common that Waypoint just doesn't support the features they need (such as all the various fields in a Kubernetes or Nomad job).

We can't make these patterns "just work" via plugins today because Waypoint's core data model and logic has an implicit expectation that each deployment is repaved. Core data model changes are necessary to support a mutable deployment model.

Supporting existing Nomad jobfiles and features is one of our most frequently requested features both on GitHub issues and the Discuss forums. And not supporting "plain old" Nomad jobfiles sends a strange message to HashiCorp products working better together. This is something we'd like to support.

Note that we don't intend Waypoint to support any and all brownfield tooling (i.e. VM management with configuration management may be out of the question) but we do want users who are using relatively modern tooling (such as Nomad, K8S YAML, Kustomize, Helm, etc.) to be able to adopt Waypoint with relative ease.

Describe the solution you'd like
Make the core Waypoint data model "mutable-aware" by enhancing operations to support a "generation ID". Plugins can opt-in to generating their own generation IDs. By default, Waypoint will generate a unique generation ID per operation (assuming immutable workflows as we've always done).

A "generation" represents a single set of resources that have been created or reused for an operation. Matching generation IDs mean that the same set of resources are in use.

Notes
This should also address #567, #1125, and #516