Race condition between TargetIn event in StepRunner and events emission in TestStep

Nobody has claimed this yet.

The problem raises as we can't atomicly (at least without "ugly" locks in events emission) pass the target to the test step via channel and emit EventTargetIn event.

Currently we are having the following partial work-around:

https://github.com/linuxboot/contest/blob/main/pkg/runner/step_runner.go#L193

// put the target into step runner
`case sr.input <- tgt:`
// by the time we are hare, the test step could have already processed the target and emitted 100500 events
// test steps rarely emit events, so it is not a big issue. For consistency with TargetOut or TargetError I made this hack:
```
// we should always emit TargetIn before TargetOut or TargetError
// we have a race condition that outputLoop may receive result for this target first
// in that case we will emit TargetIn in outputLoop and should not emit it here
sr.mu.Lock()
if targetInfo.acquireTargetInEmission() {
if err := emitEvent(ctx, ev, target.EventTargetIn, tgt, nil); err != nil {
sr.setErrLocked(ctx, fmt.Errorf("failed to report target injection: %w", err))
}
}
sr.mu.Unlock()
```

Start at pkg/runner/step_runner.go around line 193 and trace how StepRunner sends targets through its input channel, how TestStep emits events, and how outputLoop handles results. Reproduce or reason through the ordering race between EventTargetIn and TargetOut or TargetError, then define a synchronization approach that preserves the required event order and verify it with the existing test suite.

Written by the indexing model from the issue text.