Provide extended support for EOL Volto frontend images

[fredvd]

See the discussion on #67

The community would like to provide images for Volto releases that are already out of the official support that was planned and decided by the release managers/release team. In this case we could patch/run Volto 16 with an updated Node release, allthough it is officially not supported and there could be caveats or small issues.

Still: if support teams or integrators absolutely need to keep an older Volto releases running beyond the 'EOL' date for whatever reason, it would be a community waste not to document the solution and provide tools/images for this purpose.

IMHO this is a similar, but 180 degrees related issue to the discussion on plone-backend ( plone/plone-backend#167 ), where we would like to incubate including newer dependencies and tooling in the images, also without breaking the image configuration that was used when the Volto Frontend or Plone Backend major-minor version was first released. The suggestion for plone-backend in the linked discussion iirc is to use '-next' suffix an incubator 'bleading edge' version.

For the plone-frontend situation with Node and Volto 16 one of the isuea is to use node22 as a suffix. My personal concern is that if some other component that we use in the images breaks, we will have even more combinations and maybe need to combine them.

Proposal:

• version only is the image 'state; with all dependencies that was deemed stable and ok at the time of the Volto/Plone release.
• -next are possible incubator versions where we try out newer versions or substituations of components while the volto/plone release is still in suport
• -extendedsupport / extsupport/ eolsuport / naming-is-diffcult-lets-disucss suffix for images that we try to keep functional after offiial volto/plone support has ended.

For the last we should not release any major version only labels, we only pin on major.miinor.patch, So that no one can pin a 16-eolsupport and have their ci/cd breaking when we release a new version. where node18 has suddenly become node24. One has to check every release on this suffix on its merits.

And if you don't like the built image, then use it as inspiration for an internal Project Dockerfile, but we at least provide source code docs to the community.

@sneridagh @davisagli @ericof @avoinea @mamico ?

[sneridagh]

+1 to go the suffix way. I'm ok with whatever literal we choose.

My only concern is what happens when the images stops building and we cannot make them work anymore. I guess that if we ever get there, we will manage.