[universal] Avoid invoking {docker,ssh}-init.sh twice

This is both a fix and a simplification. It's a simple change (simply
remove the `ENTRYPOINT` from the Dockerfile, but understanding why it's
correct needs a bit of context:

In a devcontainer with `overrideCommand`=_true_ (which should be the
default according to the devcontainers documentation, but actually isn't
in GitHub Codespaces—more on that further down), this `ENTRYPOINT` isn't
used and hasn't actually been needed for quite a while [1], as
devcontainer features can supply additional entrypoints that are always
run regardless of `overrideCommand` [2]. These are stored in the image
metadata that the devcontainers CLI fetches and respects:

    $ regctl image inspect --format='{{json .}}' -- \
            mcr.microsoft.com/devcontainers/universal:2 \
        | jq -r '.config.Labels."devcontainer.metadata"' \
        | jq -r '.[].entrypoint | select(.)'
    /usr/local/share/ssh-init.sh
    /usr/local/share/docker-init.sh

[1]: https://github.com/microsoft/vscode-docs/blob/424848fa6b6c3382ae341fecdbe08df561f1c961/remote-release-notes/v1_64.md?plain=1#L5
[2]: https://github.com/devcontainers/cli/blob/7178cebfa88e070439903fd975b7602e7b3f6dc7/src/spec-node/singleContainer.ts#L387-L399

The init process (pid 1) in such a container looks like this, which is
exactly what is desired, as the entrypoints are invoked in sequence,
each once:

    $ < /proc/1/cmdline xargs -0 printf "%q\n"
    /sbin/docker-init
    --
    /bin/sh
    -c
    'echo Container started'$'\n''trap "exit 0" 15'$'\n''/usr/local/share/ssh-init.sh'$'\n''/usr/local/share/docker-init.sh'$'\n''exec "$@"'$'\n''while sleep 1 & wait $!; do :; done'
    -

Now if one creates a devcontainer from the universal image with
`overrideCommand`=_false_ on the other hand, the init process command
line looks a bit different:

    $ < /proc/1/cmdline xargs -0 printf "%q\n"
    /sbin/docker-init
    --
    /bin/sh
    -c
    'echo Container started'$'\n''trap "exit 0" 15'$'\n''/usr/local/share/ssh-init.sh'$'\n''/usr/local/share/docker-init.sh'$'\n''exec "$@"'$'\n''while sleep 1 & wait $!; do :; done'
    -
    /usr/local/share/docker-init.sh
    /usr/local/share/ssh-init.sh
    sleep
    infinity

In addition to invoking the entrypoints from the docker image metadata
(see above), the `exec "$@` bit invokes the `ENTRYPOINT` and `CMD` from
the universal Dockerfile. This results in both docker-init.sh and
ssh-init.sh being invoked twice during container startup.

The ssh-init.sh script happens to handle this gracefully. It uses
`start-stop-daemon … --start --pidfile /run/sshd.pid …` which does
nothing if the process is running already.

The other one, docker-init.sh, isn't as smart unfortunately. The first
thing it does is it forcefully removes all `docker*.pid` and
`container*.pid` regardless of whether any dockerd/containerd is
running, then starts a new dockerd, then checks whether the daemon
starts healthy, and proceeds to pkill everything and repeat if not.
A typical universal image devcontainer startup thus looks like this:

1. ssh-init.sh runs for the first time
2. sshd is started
3. docker-init.sh runs for the frist time
4. dockerd is started
5. after some wait, dockerd is considered healthy, docker-init.sh exits
6. ssh-init.sh runs again, but that's a no-op
7. docker-init.sh runs again
8. dockerd.pid and containerd.pid are removed
9. dockerd is started again, so we have two dockerd instances
10. docker info no longer considers the daemon healthy
11. after 5 attempts to determine dockerd health, it gives up
12. pkill dockerd/containerd which kills both instances
13. start dockerd again
14. try docker info again
15. this time it finally succeeds, but oh god it's taken a while!

The final piece of the puzzle is understanding how I ended up with
`overrideCommand`=_false_ in the first place. Truth be told, I don't
quite fully understand this yet. All I've done is used the following
devcontainer.json in GitHub Codespaces:

    {
      "name": "my first slightly disappointing devcontainer",
      "image": "mcr.microsoft.com/devcontainers/universal:2",
    }

The proprietary code (they call it the "agent"?) that sets up the
devcontainer in GitHub Codespaces creates
`/workspaces/.codespaces/shared/merged_devcontainer.json` with the
mounts and capabilities and other environment-specific additions. For
reasons I don't yet understand (but I'm waiting for GitHub Support to
explain), it also sets `overrideCommand` to _false_. And it only seems
to do it if the universal image is used, it's kept at its default value
if one happens to use e.g.
`mcr.microsoft.com/devcontainers/base:1-bookworm`.

I mean, the change in this commit makes sense even in the absence of
this weird behaviour of GitHub Codespaces. But it does mean that this
likely affects other people using the universal image, and should be
fixed sooner rather than never.

src/universal/.devcontainer/Dockerfile

@@ -93,8 +93,6 @@ RUN apt-get clean -y && rm -rf /tmp/scripts
 # Mount for docker-in-docker 
 VOLUME [ "/var/lib/docker" ]
 
-# Fire Docker/Moby script if needed
-ENTRYPOINT [ "/usr/local/share/docker-init.sh", "/usr/local/share/ssh-init.sh"]
 CMD [ "sleep", "infinity" ]
 
 # [Optional] Install debugger for development of Codespaces - Not in resulting image by default