Create a companion container for CA certificate handling

This is a spin-off of #538, originally posted there; created a new issue at request for easier discussion.

CC: @gaeljw you've opened #293 and also #464, I'd like to have your input whether this would work in your environment.

I've been writing a comment addressing @tianon's [point about scope creep](https://github.com/docker-library/docs/pull/2338#issuecomment-1593765498) and have instead thought of a way to _maybe_ keep multiple sides happy, while reducing pain points, in particular:

* People feeling the scope creep and maintenance burden
* People not liking the entrypoint requirement
* People wanting to inject CA certificates into JRE trust stores.

The idea is to use a companion container image, maintained either inside or outside of Adoptium project, which would contain most of the logic in the current entrypoint and could be used as an init container.

It would work somewhat like this:

1. Start you main container as an init container, copy the `cacerts` file from it to a temporary volume.
2. Start the companion image as a second init-container with your custom certificates and temporary volume from step 1 mounted; combine both to a new `cacerts` using the existing logic from the entrypoint script of `eclipse-temurin`.
3. Start your main container with an added volume mount containing the new `cacerts` file and an added environment variable `JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStore=/volume/cacerts -Djavax.net.ssl.trustStorePassword=changeit`.

This would probably make the Kubernetes camp happy, since it directly maps onto Kubernetes way of doing things. Docker camp would need something like `docker compose` with [service_completed_successfully](https://docs.docker.com/compose/startup-order/#control-startup), but this is probably still manageable in a similar way.

If this companion image were to be maintained inside the Adoptium project, we might get away with just including the default `cacerts` and thus only needing one init container instead of two. No idea how dependant this is on the actual JRE version, maybe there is some common source for the `cacerts` file?

We'd also need the following steps in Adoptium project:

* Freeze and deprecate current entrypoint-based certificate implementation, add a deprecation warning
* Document the recommended implementation process
* At some point in the future: remove current certificate functionality, possibly remove the entrypoint altogether.

Start by locating the existing eclipse-temurin entrypoint script and its certificate-handling logic. Review how a companion image and init-container workflow could reuse that logic, then determine the documentation and deprecation steps needed for the proposed replacement; done means the approach is agreed and its implementation scope is defined.

Written by the indexing model from the issue text.