[ps2]

Adds hangUpOnNextMessages: on each of the next count messages, the pod hangs up, then takes the phone's reconnect as usual.

• {"command": "hangUpOnNextMessages", "value": 1} hangs up when the message arrives, without answering, as a pod that drops the link during a command does.
• With "afterAnswering": true it answers, waits for the phone's ACK, then hangs up, as a pod that drops the link soon after a command does.
• On -transport impossible the phone gets CoreBluetooth's "peripheral disconnected" error (CBError 7), the way a pod's hang-up reaches a phone. On a Bluetooth adapter it's an ordinary disconnect from the pod.

The simulator could already leave a message unanswered with the link up (ignoreNextMessages), fail a connect during setup (failNextConnects), or exit (crashNextCommand). None of those is a pod-initiated drop that leaves the pod available, which is the case in the loopandlearn/OmnipodKit#209 review: a pod that hangs up during or after a command, with the phone in the background.

Testing

• go test ./pkg/... passes. A new test checks that the hang-up carries CBErrorDomain 7 and that the next connect is accepted.
• Used against Loop (next-dev with Log each connect's setup and every failed exchange and disconnect; don't mark unsent commands unacknowledged loopandlearn/OmnipodKit#209) in the iOS Simulator through ImpossiBLE, with the app in the background on a heartbeat probe:

  pod:  hanging up on message seq 4 without answering (hangUpOnNextMessages)
  pod:  ** disconnected by the pod
  app:  [disconnect] CBErrorDomain 7, 0.010s after connect, during session Get pod status, setup ok
  app:  [read] emptyValue at RTS after 5.084s, link already down; …
  app:  Unacknowledged message. seq:6, error = incorrectResponse
  

  and with afterAnswering, the status read completes and the drop follows it:

  pod:  hanging up after answering message seq 4 (hangUpOnNextMessages)
  app:  [disconnect] CBErrorDomain 7, 0.017s after connect, during session Get pod status, setup ok