Add stacks automation to central repo

[fg-j]

Summary

To implement paketo-buildpacks/rfcs#197 and paketo-buildpacks/stacks#133, the new stacks repositories require new automation.

The automation checked in here is based on my fork of the jammy-tiny-stack repository. Most of the automation included here is already running on the fork.

There are a couple of notable differences between this PR and the automation implemented on the jammy-tiny-stack repo:

• There is one Create Release step in the release workflow instead of two. The list of release assets is now constructed before the release step, and accounts for the with- and without-USNs cases.
• There are a couple of places where the jammy-tiny-stack automation hard-codes names related to the stack and/or linux distribution. I've added steps that parse this info from the Github repo name. These enforce/expect the same repo naming scheme outlined in the Jammy RFC and Bionic Updates RFC.
• The create release and push image workflows use the newly refactored File Issue action in this repo.

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[robdimsdale]

@fg-j what needs to be done for this PR to be taken out of "draft" and become ready for review?

[fg-j]

Basically, I just need to shift some of our refactors out of the jammy tiny stack and move them here.

[ForestEckhardt]

I would appreciate some form of testing for the actions that are written in Go as I imagine that they are the actions that are the most complicated and if they needed to be changed in the future then having tests would be a great benefit.

[sophiewigmore]

@ForestEckhardt agreed that testing would be very useful here. Considering we've already started moving forward with the Jammy base/full stacks, would you be comfortable with the addition of testing as a separate PR? I'm thinking that may be the move so that the new repositories can be built from the get go with the shared tooling. If not, those repositories will probably just use copies of what Jammy Tiny has anyways, which are untested

[sophiewigmore]

The changes here look good to me

[ForestEckhardt]

@sophiewigmore For sure, could we just get an issue to track that really quickly and then I am good to go.

[fg-j]

#482 can be transferred to this repo

[ForestEckhardt]

@fg-j Do you have issues for diff-package-receipts and release-notes as well or do those need to be generated?

[fg-j]

There aren't issues for those. I can expand the issue to include coverage for those actions as well.

[sophiewigmore]

@fg-j can you also update the github-config repo update-tools workflow to include bumping the stacks-related tools?