Add additional details to cache metadata

[jabrown85]

Summary

After discussing this issue in the working group, we came to the conclusion a first good step would be to add additional information to the cache metadata so lifecycle can begin to make decisions regarding the cache in the future.

I propose starting by adding the stack, platformVersion and potentially architecture to the cache metadata file.

# io.buildpacks.lifecycle.cache.metadata
{
    "stack": "heroku-20",
    "architecture": "amd64",
    "platformApi": "0.6",
    "buildpacks":[
        ...
    ]
}

Some things this may allow lifecycle to do with this information in the future:

• Look for cache layers named differently if we decide to change naming scheme or cache format
• Ignore restoring cache when the stack or architecture do not match

[natalieparellano]

This seems like something that may require an RFC. Do we want to label it as such?

[natalieparellano]

From #471:

We should also consider checking whether the layers in the cache were created for the correct stack ID. If we decided to do this:

We will need to store stack ID in the cache metadata. For backwards compatibility, in cases where the cache metadata is missing the stack ID we should be optimistic and assume the layers were created for the correct stack.

[natalieparellano]

With stack removal, the stack ID wouldn't need to be stored - but as we progress toward multi-arch we should be storing target data in the cache so that we don't end up restoring wrong layers when images are built for a new platform with a re-used tag.

[natalieparellano]

Potentially related (discarded) RFC: https://github.com/buildpacks/rfcs/pull/227