Supersedes #235

Instead of using a TreeView and the obvious shortcomings of not being able to use Gtk.Widgets anymore to construct the list of conversations, this PR implements a custom ListBox implementation that is much more efficient than the GTK one.

Instead of creating a Gtk.Widet for every single row in the ListBox, visible or not. We use a pool of a small number of widgets that get recycled/re-mapped to the underlying datastore as they scroll in and out of view. The sizing of the scrollbar is worked out on the average height of each row, multiplied by the number of rows in the data store. So, for ListBoxes where every row is an equal height (like in this case), the scrollbar is perfectly mapped. For varying height widgets, it works reasonably well, but you see some slight amount of jumping in the scrollbar, especially for small lists.

This implementation is not perfectly API compatible with the existing GTK ListBox, but I've tried to keep quite a few of the property names the same to make transition reasonably easy. I think using this in Mail and seeing how well it works out and seeing if anything needs fixing or adding would be a good thing. Then it can be moved out to Granite if it's useful elsewhere or I'll look at porting it to C and submitting upstream.

My gmail inbox has ~12000 items and master will not load that folder at all, even after leaving it 10+ minutes. It just keeps burning through memory and never actually loading. With this, it loads in <1 second (note: there is a separate issue where if the folder has changed, the EDS backend refreshes the folder before Mail displays anything, which takes a short while). The best way to test is to allow mail to load a folder for the first time and then switch back and forth between two folders, as this is purely the speed of populating the listbox rather than waiting for the mail backend.

Still to do:

• Check I haven't broken anything during the merge and branch name changes
• Fix code style
• Add documentation