Don't remove reflector messages in `setState` sent after the action.

When updating the message queue to match the incoming specification,
`setState` previously cleared the queue except for messages with a
`respond` field. But that would delete messages sent after the
`setState` that arrived before it finished executing. Those messages
apply to the new state and should be retained.

The correct process is to delete all future messages, including any
generated during the `setState` since the incoming queue contains the
correct messages for the new state, delete any reflector messages that
arrived before the `setState` but were scheduled to execute at a later
time, but retain any reflector messages that arrived after the
`setState`.

Fixes #2122.
Schedule future actions in front of reflector actions at the same time.

Previously, if future and reflector actions were placed in the message
queue with the same execution time, they would be arranged in order of
arrival. But this would leave the queue in an indeterminate state. Since
reflector messages arrive at different clients at different times,
clients wouldn't order these sequences consistently.

Additionally, it's probably expected that when an action generates a
future action at delta time 0, the new action will run before a new
external action executes--even if an external action for the current
time has already arrived.

Now, the message queue is sorted first by time, as before, then by
origin to place future actions in front of reflector actions, then by
arrival order, as before. This ensures that a sequence of future
actions, including one that generates new actions for the same time,
will always run to completion before a reflector action executes,
regardless of whether the external action arrives before, during or
after the sequence starts executing.

Fixes #2123.