add docker wrapping rewrite ENTRYPOINT mode

## Description

currently when docker entrypoint is wrapped, it is wrapped exclusively via container config via `Dockerfile`:

```docker
FROM alpine
ENTRYPOINT ["/foo"]
CMD ["bar"]

# chalk wraps with:
COPY chalk /chalk
ENTRYPOINT ["/chalk", "exec", "--exec-command-name", "/foo", "--"]
CMD ["bar"]
```

This works as long as the entrypoint is not overwritten anywhere the container runs. As soon as the entrypoint however is overwritten (possibly in AWS/k8s deployment), chalk will not run anymore:

```
docker run -it --rm --entrypoint=sh
```

We could add a rewrite entrypoint mode where the premise is for chalk to replace the entrypoint binary. For the above container something like:

```docker
FROM alpine
ENTRYPOINT ["/foo"]
CMD ["bar"]

# chalk wraps with:
RUN mv /foo /foo.nonchalked
COPY chalk /foo # note chalk is copied to /foo, not /chalk
```

Then internally `/foo` (as it is chalk now) will know to execute `/foo.nonchalked` (original entrypoint). This way we can guarantee anytime original application entrypoint binary is executed, chalk will exec as well.

As this changes original application binary, this mode should be optional and enabled via explicit config. Maybe something like:

```
docker.rewrite_entrypoint: true
```

This way the behavior can be customized for the comfort level of the user on how chalk customizes the container.

## Result

Wrapped container will exec chalk no matter how its customized in the deployment configs (aws, k8s, etc)

Start by reviewing the Dockerfile wrapping flow and the entrypoint configuration handling described in the issue. Trace how the current /chalk wrapper is selected, then determine where an explicit docker.rewrite_entrypoint option would be integrated. Done means an opt-in mode replaces the original entrypoint while preserving execution of that original binary when deployment configuration overrides the container entrypoint.

Written by the indexing model from the issue text.