Bug 796474 - [email] quasi-infinite scroll may hitch under OMTC

This ticket introduces a virtual scroll mechanism, where not all message item divs are rendered at once, but just a subset that is near and in the visible area, with that set updating as scroll position is changed.

message_list now uses vscroll to handle the message items shown in the messages_list. vscroll uses a set of NodeCache objects that each have a set of reusable nodes to use for messages, and as the scroll happens, the NodeCache divs are repositioned as needed and their contents updated. As the user scrolls across the current NodeCache, after it is scrolled by about 20% of its size, a "prepareData" call is used to ask the back end to load more data.

That approach was used since the backend prefers to load data in chunks, and it was hoped that the fewer, bigger divs to move around in the scroll area was better overall. That needs to be balanced though by how much processing power the back end needs to fetch those chunks, and if the updates to those NodeCache sets touch enough nodes as to create a drag on performance.

It seems to work out well with APZC turned on. However, with APZC turned off, it does not perform as quite as nice, and those workloads may need to be tuned if there is a case where this code is used in a non-APZC, low capability device.

There are some changes to these files that are just jshint fixes, see the jshint/xfail.list for the ones that have the changes. Those changes were done in files that had a big enough changeset already that the extra jshint changes should hopefully be smaller noise.

worker-bootstrap.js shows a whitespace change in there, related to CRLF conversions. I am unclear yet on why I am seeing that now, as I do not recall changing my GELAM or Gaia settings in that regard.