Ensure graceful shutdown in GenericContainer.stop() (#10365)

[taole33]

Issue #10365

Motivation

This PR addresses Issue #10365 where the trap signal in a container script is ignored when GenericContainer#stop() is called.

The root cause is that GenericContainer#stop() currently delegates the stop process directly to ResourceReaper#stopAndRemoveContainer(), which issues a killContainerCmd (SIGKILL). This prevents the container from performing any graceful shutdown tasks (e.g., closing connections, flushing logs, executing hooks).

This PR modifies GenericContainer#stop() to attempt a dockerClient.stopContainerCmd() (SIGTERM) before delegating removal to the ResourceReaper.

Changes

Modified GenericContainer#stop() to issue stopContainerCmd before calling ResourceReaper.
Added testPostHookExecutionOnStop in GenericContainerTest to verify that trap hooks are correctly executed upon stopping.

Discussion / Concerns (Reason for Draft)

I am submitting this as a Draft because changing the default behavior to stopContainerCmd implies that stop() will now wait for the container to exit.

Pros: Correctness. Containers can handle lifecycle hooks properly.

Cons: Potential performance regression in tests where containers ignore SIGTERM, causing a delay of up to 10s (default timeout) per test.

I have verified locally that well-behaved containers (which handle SIGTERM) stop almost instantly, so the performance impact should be minimal for correct implementations. However, I would like to hear the maintainers' opinion on whether this should be the default behavior or if we should introduce an opt-in configuration (e.g., .withShutdownTimeout()).

[eddumelendez]

Thanks for your contribution, before raising a PR please wait until the issue is triaged.