Determine 3.0 container_init downstream customization workflow

[nitzmahone]

The upstream default container init in 3.0 just always installs dumb-init from PyPI in the absence of any other config in the EE def. That's probably not going to be palatable for downstream- dumb-init is publicly packaged for Fedora, but not for CentOS Stream/UBI/RHEL. A few ideas:

1. Add an optional "is dumb-init already here?" script check that will skip the pip install if found, since I assume we'll continue to manually add it on the official downstream base images anyway. So long as the check passes, continue to configure the entrypoint defaults as we already do, or stop with a clear failure message if the base image doesn't already have dumb-init and say that the user will need to install one from "somewhere".
2. Vendor a container init binary into the downstream packages and provide a simple place for downstream to patch to copy it in as the default instead of pip-installing. This causes problems for multi-arch and non-standard C runtimes, among other things.
3. Do nothing, and tell downstream users that have a problem with the default pip-install to get dumb-init or another init system from "somewhere".
4. (dream scenario) Get all AAP components that launch an EE to tell the container runtime to inject an init (as both docker and podman support this, and I assume others do as well), and let builder get out of the business of providing a default init entrypoint altogether. This may not be realistic.

Option 1 is probably the most realistic, since it only requires users that aren't based off a fully-supported base EE to understand this and make a choice (and even then only if their builds can't access pip, unless the downstream builder bits patch that default away).