[main] Parallelize per-sample test-pack generation in PipelineTestPackWriter

[hugohills-regnosys]

Summary

• PipelineTestPackWriter.writeTestPackSamples() generated every sample in a test pack sequentially on a single thread, even though each sample is fully independent (own input file, own output file, own SampleModel). For models with large test-pack suites this loop dominates update-expectations runtime — observed on one large test-pack suite: tens of thousands of samples at tens of milliseconds each, adding up to double-digit minutes, single-threaded.
• The inner per-sample loop is now driven by inputSamplesForTestPack.parallelStream(), with the per-sample body extracted into a new generateSample() method. Output is still re-sorted by sample ID afterward, so file layout and generated config JSON are unchanged — only generation order and wall-clock time.

Thread-safety review

Before parallelizing, I checked every piece of shared state samples pass through:

• RosettaTypeValidator, WorkflowPostProcessor and its constituent PostProcessSteps (ReKeyProcessStep, GlobalKeyProcessStep, UpdateTemporaryKeyProcessStep, ReferenceResolverProcessStep, QualifyProcessorStep), and generated Rosetta functions all create their mutable state fresh per call and hold only immutable config/factory fields as instance state — safe for concurrent invocation.
• The one real hazard: a single javax.xml.validation.Validator was built once per test pack and reused across all its samples. Validator is explicitly documented as not thread-safe. PipelineFunctionRunnerProvider/PipelineFunctionRunnerProviderImpl/PipelineFunctionRunnerImpl now take/hold a Schema instead and call schema.newValidator() fresh per run() invocation (cheap, and Schema is safe to share across threads). TransformTestExtension (the only other consumer of this provider) is updated to match.
• ValidationSummariser.addValidationReport(...) is called per sample; since it's a caller-supplied interface with implementations outside this repo, the call is now synchronized rather than assumed thread-safe.

Test plan

• mvn test-compile — compiles cleanly.
• mvn test — all 94 tests pass, including PipelineFunctionRunnerImplTest (updated to mock Schema.newValidator() instead of injecting a Validator directly), PipelineTestPackWriterTest, PipelineTestPackWriterDefaultSerialisationTest, TransformTestExtensionDefaultSerialisationTest.
• Downstream: re-run a large model's update-expectations build to confirm wall-clock improvement and that generated expectation files are byte-for-byte unchanged.