Dependencies V2 Playground #2099

This adds support for the dependencies-v2 experimental flag when building a bundle. * Add dependency v2 fields to the porter.yaml manifest * Represent v2 deps in the bundle.json * Determine which dependency extension is used by a bundle * Have separate packages for the dependencies v2 cnab extension, and its implementation * Consolidate extensions definition into a single file * Match file names to contained structs in pkg/cnab Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

The name field for a dependency is not in the spec because CNAB represents a dependency as a map entry, keyed by name. We use a name internally just to make things easier while working with dependency entries but they shouldn't be written out with a name field. Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

mybuns = a test bundle that contains as many features / test cases we can squeeze into a bundle, without making a bunch of paramters required so that it's easy to run. Long term I want to remove dependencies from this bundle though and switch to using a new set of bundles just for dependencies. myenv = a metabundle that is comprised of its dependencies. Has a deep dependency graph. myinfra = a bundle that creates infrastructure and generates outputs that parent bundles would want to consume. myapp = a bundle that deploys an application and requires a db connection string mydb = a leaf bundle that creates a db and outputs a connection string Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

* resolve a dependency graph * identify the order of execution * create new call path to execute bundles from a workflow (i.e. jobs) * Add secret strategy for resolving data from the workflow * Support workflow wiring Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com> wip: porter strategy Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>