Fix phase outcomes after stops and retries

On a real bench, a teardown that ran after a failure showed as stopped, exhausted retries kept the run going, and a phase could read another phase's results only when scheduling happened to allow it. Each case now behaves the same way every run.

• Fixed teardown phases to report their own outcome after a stop, so a power-off that crashed shows ERROR with its message instead of a silent STOP
• Fixed then: retry so a phase whose retries run out follows on_first_failure, and so a setup phase retries before cancelling the run
• Changed phase.stop() after a failed measurement to read FAIL, so the defective unit enters the failure statistics
• Changed phase results to be visible only to phases that declare the dependency with depends_on or run in a later stage; procedures that read a sibling phase without declaring it must add the entry
• Updated the framework docs: outcome order, when to fail or raise, data sharing between phases, previous attempt on retry, retry exhaustion, phase start order and workers