[Bug]: Inconsistent name in log message when using `withStartupTimeout`

Module

Core

Testcontainers version

1.18.0

Using the latest Testcontainers version?

Yes

Host OS

Ubuntu 22.04

Host Arch

AMD64

Docker version

Client: Docker Engine - Community
 Version:           23.0.3
 API version:       1.42
 Go version:        go1.19.7
 Git commit:        3e7cbfd
 Built:             Tue Apr  4 22:05:48 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          23.0.3
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.19.7
  Git commit:       59118bf
  Built:            Tue Apr  4 22:05:48 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.20
  GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc:
  Version:          1.1.5
  GitCommit:        v1.1.5-0-gf19387a
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

When using withStartup, the image name in the log message is incorrect.

Example:

Creating container for image: azul/zulu-openjdk:20
/beautiful_ellis: Waiting for 30 seconds for URL: http://localhost:34418/ (where port 34418 maps to container port 8888)
Container azul/zulu-openjdk:20 is starting: b24b61a259435efb3764a79f2510957dfc22dd28e2e52419dc21f2701016a1df
Container azul/zulu-openjdk:20 started in PT5.177405S

/beautiful_ellis should be beautiful_ellis (no forward slash) to align with docker container ls output.

---

The message may also benefit from some rewording, such as...

Image beautiful_ellis waiting for 30 seconds for URL: http://localhost:34418/ (host port 34418 maps to container port 8888)

... but if user code is parsing the message, it may break.

Relevant log output

No response

Additional Information

No response

Start at the Core container startup logging path used by withStartupTimeout and reproduce the example with the azul/zulu-openjdk:20 image. Check how the container name is formatted in the waiting message and compare it with docker container ls output. Done means the message uses beautiful_ellis without a leading slash, with regression coverage for the reported case.