Session view rendering performance improvements and testing

This change set more or less resolves #205, the tremendous UI slow-down we saw when there was lots of session-related activity during an unhangout. The root of these issues was twofold:

 1. Rendering a single session view was relatively slow (50ms-100ms)
 2. We rendered session views ALL THE TIME - we sorted all the sessions in the list whenever any of them updated because we were trying to maintain a most occupied to least occupied ordering. This made updating any session an N^2 operation, and it happens a ton when you have 80 people joining/leaving hangouts.

I figured this out by adding some debugging code to fake lots of session activity for testing purposes. It can be enabled by uncommenting `this.setupSessionActivityEmulation()` in `ServerEvent.init` and opening sessions on an event. That will trigger random join/leave events once every second on all sessions in the event.

In terms of performance improvements, there are three changes:

 1. stop sorting sessions by the number of participants, just sort by title a-z when sessions are added
 2. stop creating and destroying userviews on every render when there are users in the hangout; cache those views instead since they change with relatively low frequency.
 3. When assembling lists of userviews in a session, use document fragments to avoid touching the dom quiet so frequently during that operation.

This brought rendering down to ~30-50ms, and the number of renders in high load situations way way down.