Fixups for lifecycle 0.17.0

[natalieparellano]

In reviewing the work that has been done already for the next set of APIs, some gaps were identified between the desired implementation and the actual implementation. Probably more gaps will be identified in working through the pack implementation. This issue is meant to be a catch-all issue but each gap is likely small and could be considered a "good first issue".

TODO:

• More sophisticated error checking when we fail to get a layer from a sparse image (see FIXME in exporter.go)
• Write both stack and runImage in the metadata label for backwards compat
• Extensions should expose target data & the lifecycle should validate it (just like buildpacks)
• analyzer prints out Ignoring image "previous-image-name" because it was corrupt when the previous image is just missing
• ...more to add here

In flight:

• extender: better uid checks and error if it stay as root #1093 - Extender: if the final user after all Dockerfiles have been applied does not match the CNB_USER_ID, we should warn
• extender: better uid checks and error if it stay as root #1093 - Extender: if the final user after all Dockerfiles have been applied is root, we should fail
• Add history when adding buildpack or extension layers #1099 - Right now there's no good way to map extension layers back to the extension that created them (for buildpacks we have io.buildpacks.lifecycle.metadata with key buildpacks). Keeping track of the extension <-> layer SHA mapping is possible, but might require the introduction of a new extended.toml (or something) file

Done:

• Detector: if the run image based is switched by an image extension we should verify that the new base exists in run.toml (need to verify that run.toml path is an input to the detector, and if not, update the spec PR) (we made this a warning instead)
• Support for OCI layout (there were some issues using imgutil's sparse package, shouldn't be a huge change but needs time to work through) (making a separate issue for this)

[joe-kimmel-vmw]

Should extensions expose and/or the lifecycle validate target data for extensions?

It seems to me like something is warranted here -- e.g. if i'm writing an extension that uses a package manager like apt, yum, apk, nix, etc., then I would want that extension to only run on the appropriate distribution of linux and I might even be interested in writing several extensions in order to support multiple distributions or package managers. But maybe that's a rare use-case?

[natalieparellano]

Will be closed by #1108 and #1109