Run opted-in tests concurrently with a concurrency limit

Summary

Support explicitly concurrent test cases with a configurable in-engine concurrency limit while preserving sequential execution by default.

Why

Independent asynchronous tests can spend most of their time waiting on promises. Opt-in bounded concurrency can reduce runtime, but it needs defined hook, microtask, statistics, and failure semantics rather than reusing file-level workers.

Current behavior

TGocciaTestAssertions.ExecuteSuite walks registered entries sequentially and updates shared test statistics/current-test state. --jobs runs separate files in parallel but cannot overlap tests within a file. Closed #114 explicitly deferred test.concurrent.

Expected behavior

• Add an explicit concurrent test registration form; ordinary tests remain sequential.
• Bound concurrently active test cases with a configurable limit.
• Define suite ordering and beforeAll/afterAll/beforeEach/afterEach behavior for mixed sequential and concurrent entries.
• Isolate per-test assertion counts, timeout state, failures, and microtask completion.
• Keep result ordering deterministic even when completion order differs.
• Produce equivalent behavior in interpreter and bytecode modes and compose safely with file-level --jobs.

Scope notes

• Do not make all tests concurrent or infer concurrency from async callbacks.
• Worker threads/process pools, cross-machine sharding, and a distributed scheduler are out of scope.
• Retry/repeat attempt semantics are a separate issue.
• Tests in one engine may still share explicitly imported mutable state; the API must document that boundary rather than silently cloning the runtime.

Start at TGocciaTestAssertions.ExecuteSuite and trace registered-entry execution, shared statistics/current-test state, and the existing --jobs path. Define the opt-in API and bounded scheduling semantics there, then add coverage for mixed ordering, hooks, microtasks, failures, deterministic results, interpreter/bytecode parity, and --jobs composition.