Build Stage Inputs and Outputs

[alexrichey]

This expands on our Roadmapping discussion on Wed April 10, and this mock PR

We'd like our builds be have an identical set of commands to run them end-to-end. ie

dcpy lifecycle build plan [path]
dcpy lifecycle build build [path]
dcpy lifecycle build qa [path]
dcpy lifecycle build publish_draft [path]
dcpy lifecycle build publish_publish [path]

One way to accomplish that is by ensuring that each stage in the build provides enough info for the next stage to start. If we were to use the existing build_metadata.json, the flow might look like this (using yaml here just for ease-of-reading)

Additionally, build.plan would need to set a few additional variables in the recipe_lock, for subsequent stages, like the BUILD_NOTE, the output directory for the build, etc.

The lifecycle functions like dcpy.lifecycle.build.build could potentially just return a path to the build_metadata.json. Then dcpy.lifecycle.build.publish_draft would have enough information to do it's thing.

We also discussed making the steps of the build explicit, and potentially including packaging and distribution, but decided that since we'd probably want similar machinery for datasets that we don't produce (e.g. we'd want to use package for LION datasets)
those type of instructions probably belong more in the product metadata repo.

There's also the consideration for how this plays with DAG tools like Prefect or Argo. But even in GHA, this would simplify things pretty tremendously.

As a first step, we should start adding additional outputs to the recipe in plan, like the build-note.

In the distant future, maybe the build_metadata (or equivalent) lives in a location that's configurable, rather than just the filesystem. Ie it could live in a builds database, or on s3, etc.