Document conventions for workers

The workerFSM abstraction is the way we implement protocol logic, and so it's likely we'll be writing and/or modifying workers to accommodate new discovery methods, transports, etc.

Implementers need to know a few things about writing workers, and this should be documented wherever makes the most sense:

Each workerFSM runs on its own goroutine. When you start a workerFSM, the worker's goroutine is created, and the worker begins executing. When you stop a workerFSM, it terminates that worker's goroutine at the conclusion of its currently executing state.

If you put a worker into an infinite loop, you must listen for its context cancellation -- otherwise, your worker will be unable to return from its current state, your worker will not obey calls to stop, and you will leak goroutines. The worker context is passed as the first argument to each FSMstate.

Similarly, if your worker creates child goroutines, it's your responsibility to figure out how to pass the worker context forward and terminate those goroutines when the worker context is cancelled.

The issue names the workerFSM and FSMstate entry points but no file or test. Find the workerFSM implementation or existing documentation, then read the start/stop lifecycle and context handling. Done means implementers can find and follow the goroutine, cancellation, and child-goroutine conventions.