Add a function-based wait strategy #1559

What happens

There is no way to say "the container is ready when this function says so". A readiness check that the built-in strategies do not cover, such as "a query succeeds" or "the topic exists", needs a class:

• subclass StartupCheckStrategy, which receives a raw Dockerode client and a container id and returns "PENDING" | "SUCCESS" | "FAIL", or
• implement WaitStrategy in full, including the timeout bookkeeping.

The usual alternative is to let start() return and then poll in the test with a hand-written retry loop.

Expected

A function-based strategy that is polled until it returns true, with the standard startup timeout:

const container = await new GenericContainer(image)
  .withExposedPorts(5432)
  .withWaitStrategy(
    Wait.forPredicate(async (container) => {
      const result = await container.exec(["pg_isready"]);
      return result.exitCode === 0;
    })
  )
  .start();

A rejected promise counts as "not ready yet", and the last error is included when the wait times out.

Where

• packages/testcontainers/src/wait-strategies/wait.ts
• a new strategy in packages/testcontainers/src/wait-strategies/

Notes

• .NET's IWaitUntil is a single UntilAsync(IContainer) method added with AddCustomWaitStrategy. Go has wait.ForNop(func(ctx, target) error), wait.ForSQL and wait.ForExec.
• Depends on what a strategy is given: with Pass the started container to WaitStrategy.waitUntilReady #1558 the predicate simply receives the container. It can be built before that by constructing the argument internally.
• Polling must use a deterministic check from the caller. This is not a place for a sleep.

Dependencies

• Blocked by Pass the started container to WaitStrategy.waitUntilReady #1558: the predicate should receive the container. It can be built first with an internal adapter if needed.