op-service: cliapp lifecycle test fix, prevent race nil-ptr on app state-access

[protolambda]

Description

Test flake, as reported by @tynes:

=== Failed
=== FAIL: op-service/cliapp TestLifecycleCmd/interrupt_start (0.00s)

=== FAIL: op-service/cliapp TestLifecycleCmd (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x6d776d]

goroutine 14 [running]:
testing.tRunner.func1.2({0x7133a0, 0xa0da00})
	/usr/local/go/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
	/usr/local/go/src/testing/testing.go:1548 +0x397
panic({0x7133a0?, 0xa0da00?})
	/usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/ethereum-optimism/optimism/op-service/cliapp.(*fakeLifecycle).Stopped(...)
	/root/project/op-service/cliapp/lifecycle_test.go:44
github.com/ethereum-optimism/optimism/op-service/cliapp.TestLifecycleCmd.func4(0xc0001dd380?)
	/root/project/op-service/cliapp/lifecycle_test.go:141 +0x6d
testing.tRunner(0xc0001dd6c0, 0xc00002f400)
	/usr/local/go/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 7
	/usr/local/go/src/testing/testing.go:1648 +0x3ad

This was caused by introspecting the state, which is available some time after init and before start of the lifecycle, but not exactly after init; this caused a rare race-condition where the Stopped state was checked on an app that was still set to nil. Instead of using a double-pointer (yes, I know, it was a bit hacky), it now uses a channel to communicate this state. (and buffered, so it's optional to read by the test-case).