Add dependencies and restart policy to s6 services

[mikelzuru]

This PR is aligned with the issue #1784

Those changes help apko to achieve a similar behavior as in s6-overlay with service-bundles, by adding dependencies between services and restart policies.

This will mimic an init-container even in serverless environments like GCP Cloud Run, which is not that straighforward currently. Furthermore, given that depends_on field (see the YAML below) is an array, we could potentially have a services dependency tree just with one container image.

The idea would be to have a YAML manifest with an entrypoint section similar to this:

entrypoint:
  type: service-bundle
  services:
    service1:
      command: /etc/myservices/service --config="/config/service1.conf"
      depends_on:
        - service2
    service2:
      command: /etc/myservices/service2 --config="/config/service2.conf" --output="/config/service1.conf"
      restart: on-failure

As a result of the above configuration, we can achieve the following:

1. service1 is the main service, but it must wait until service2 finishes
2. service2 is declared as a one-shot service (s6-overlay term) by using restart field, which means that we can force s6 to not restart service2 once correctly finished
   a. If we used restart: no, we would be telling to s6 that we do not care about the exit code of service2, thus service2 will never restart after the first execution

This change hash some extra benefits compared to s6-overlay. We remove the dependency with sh, which is still needed to properly initialize s6-overlay. Thus there is no need to add a shell or packages like busybox, which as a result provides a cleaner and more secure minimal container. All dependency and restart features are managed by strictly using the s6-supervision-suite and other tools coming by default with apko.

In addition, restart field aims to be compliant with the docker way restart policies. We could even have include restart policies like on-failure[:max-retries] or unless-stopped, but I wanted to keep the first PR simple.

Note that I also included a type change in the ImageEntrypoint struct. The aim behind this change is to keep the code backwards-compatible. Thus if you accept this proposal, current users can still use their manifests in the old-way.

I hope the main idea is clear enough. We can discuss about specific details of the code, if you do not feel 100% comfortable with this solution.