Replace the SSH launcher's fixed 10 second waits with readiness checks (#398)

[wshlavacek]

Closes #398.

The SSH cluster launcher used two fixed ten second sleeps. One came after starting dask ssh, assuming the workers were up ten seconds later. The other came after asking the cluster to shut down, assuming it had stopped ten seconds later. Both assumptions are wrong in both directions. Measured on a real SLURM cluster, the workers took 26 to 59 seconds to register, so ten seconds let the run start before the cluster was ready. On a fast cluster ten seconds is longer than necessary and every run paid it twice.

The srun launcher merged in #614 already replaced its own startup waits with real polling. This does the same for the SSH launcher and, so that the readiness check runs on a path a real cluster can exercise, pulls the polling into one method both launchers share.

Startup: setup_cluster no longer sleeps. It launches dask ssh and returns the process, the number of workers it should bring up, and the file its output was captured to. The constructor then waits for all of those workers to register with the scheduler, up to a time limit, and watches the launched process so a failed login is reported as soon as dask ssh exits rather than after a fixed wait. Requiring the full worker count also turns a quietly undersized cluster into a clear error.

Shared loop: the waiting itself is one method, _poll_for_workers, that both the srun and SSH launchers call. It watches the scheduler for the workers to register and watches the process bringing them up, and returns an outcome rather than raising, so each launcher still phrases its own error. srun keeps waiting for one worker and quotes its log; the SSH path keeps waiting for the full count and quotes what dask ssh said. Their behavior is unchanged.

Teardown: the fixed sleep is gone. Teardown now asks each process it started to stop and waits until it has actually exited, and kills one that will not stop within a bounded time.

The two time limits are named constants in pybnf/cluster.py (SSH_WORKER_TIMEOUT and TEARDOWN_TIMEOUT), matching how the srun launcher sets its limits.

Verification on a real two node SLURM cluster, using the srun launcher, which needs no login and so runs where the SSH login cannot:

• Startup: the shared readiness loop returned about three seconds after srun started, the moment the workers registered, and the fit began at once rather than after a fixed ten second wait.
• Teardown: returned in about one second once the processes exited, rather than after ten.

The SSH path adds its own worker count and its own message vocabulary on top of that shared loop; those pieces are covered by unit tests. The SSH login uses paramiko, which cannot authenticate on a host based or Kerberos cluster, so exercising the dask ssh transport itself end to end needs a cluster whose nodes accept a paramiko login.