PR17232 take #3: mutex the control messages

PR17232 take #3: mutex the control messages

As per jistone's advice, simplify control message control by imposing
a mutex over the whole receive-side handling of a ctl message.  That
precludes concurrent or reentrant messages (independent of /ctl
open-time limits or threading assumptions).  It lets the start and
exit handling functions keep track with fewer state variables.

In a way, this elaborates upon a reversion of commit #262f7598.

* runtime/transport/control.c (_stp_ctl_write_cmd): Use a new static
  cmd_mutex for ctl message handling.  Don't bother with counters and
  flags for startedness etc; let the lower level functions handle
  that.  Handle error exits via goto out instead of return to assure
  mutex unlocks.
* runtime/transport/transport.c (_stp_handle_start,
  _stp_cleanup_and_exit): Drop the stp_transport_mutex control,
  explain why unnecessary.  Be more paranoid during module-notifier
  cleanup.