…meline

Do not emit group when progress report is nested in timeline or failure.
Unfortunately github logging does not handle nested groups correctly.

Commit 606c1cb passed "isVeryVerbose" as
to argument "emitGroup", while should pass to "emitGinkgoWriterOutput".
So, it break fix added in commit fdc65b1.

Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>

Programs that drive Ginkgo programmatically — merged test binaries for large
monorepos, meta-testing of dynamically generated suites — want to run several
suites sequentially in one process: register specs, call RunSpecs, Reset,
register the next suite's specs, and call RunSpecs again. Everything RunSpecs
uses is already either reconstructed per run (reporter, output interceptor,
parallel client, progress handler) or reset by extensions/globals.Reset (the
suite and failer themselves). The one blocker is the suiteDidRun guard, which
lives in package ginkgo where Reset cannot reach it, so a second RunSpecs
always exits with GinkgoErrors.RerunningSuite.

Move the flag into internal/global as SuiteDidRun and clear it in
InitializeGlobals. Calling RunSpecs twice without an intervening Reset still
fails exactly as before — only an explicit Reset arms a fresh run.

Follow-up to #1673, covering the extensions/globals.Reset + RunSpecs pattern
in the long-form docs: when it applies, how each run behaves, and the caveats
(never Reset inside a running suite; Ginkgo resets its state but not yours;
parallelism stays one process per worker).