We do this because jsToAppend is referenced in a few
different places, and it’s better to reuse it than to try and add
commandForComets to all of those places (especially since
some of them are inside CometActors, for example).

When dealing with an AJAX request in a comet context, we
were partial-updating jsToAppend at the beginning of the
request, but any updates that might have been made to it
during the request processing were lost. We now send the
partial update message after the request functions have run,
so that any JS they’ve appended also gets sent down to the
client.

If a comet was sent down from within a comet context, we
would force a comet request reset. On the client, this would
schedule a new comet request and attempt to abort the old
one; however, there is no way to abort the old one, since its
success handler is what is kicking off this request reset.

The end result is that the request’s success handler finished
running, which would also schedule a new comet request,
and we’d get two comet requests running in parallel and
walking all over each other.

When generating the comet commands, we now check to
see if we’re executing in a comet context, and if we are we
ask the client not to reset the comet cycle, knowing that the
response we’re currently sending will immediately kick off a
new request once it’s done executing.

We now pull jsToAppend handling out of the message
handler for comet-context AJAX request processing all the
way to the wrapper around handling all messages. This
ensures that things like partial updates will properly render
their JS to append.

It also seems to incidentally fix S.jsToAppend within comet
rendering, which seemed to trigger the JS twice instead of
just once before this.