Update to latest gtk-sharp API that adds I* prefix for interfaces
ListView: fix default cell background colour

In Banshee's GTK2, the default cell background colour is white (taking
in account the default theme of Ubuntu 13.04). In Banshee's GTK3 however,
this was being drawn as grey, the same grey that is used for RulesHint
enabled rows and SortedColumn rows, so it was preventing the latter
effects to work. By using the "cell" StyleContext [1] instead of the
"view" one [2], this appears to be fixed.

[1] https://developer.gnome.org/gtk3/3.5/GtkStyleContext.html#GTK-STYLE-CLASS-CELL:CAPS
[2] https://developer.gnome.org/gtk3/3.5/GtkStyleContext.html#GTK-STYLE-CLASS-VIEW:CAPS
ListView: always render background for all cells

Previous commit[1] that replaced the VIEW class with the CELL one was
not actually correct. By looking at the GtkTreeView code from master[2]
we can notice that the VIEW is used at first, but the CELL is also used
later, when drawing the cells.

In hyena, the background of the cells was only being drawn when the
RulesHint property was TRUE and the cell parity was odd, assuming
that the background of a normal (even parity) cell would always match
the background of the widget in the first rendering phase (when the
VIEW class is used). Well, this assumption is not correct as soon as we
find one case that refutes it: Ambience, the default Ubuntu (13.04)
theme. Because of this, we need to draw the background of all cells
(with the CELL class added, yes) regardless of the RulesHint property
or the parity.

Now, you may ask why after these 2 commits the rules still don't
appear to work in Banshee GTK3? Well, we have to blame now the theme,
because even if some work was done[3] in the past to allow stripped
treeviews in general (affecting all apps which used GtkTreeViews
configured with rules-hint==True), the bug has re-appeared again,
and its fix wouldn't even work yet with Banshee (because it targets
just the GtkTreeView particular widget instead of using the CSS class
CELL mentioned earlier).

[1] https://git.gnome.org/browse/hyena/commit/?h=gtk3&id=fd1adee656c0cb8be825f5e9b02c686cb1e46e3f
[2] https://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c
[3] https://bugs.launchpad.net/bugs/945430
ListView: work-around possible selection GTK3 Theme CSS bug

In the case these two rules are defined in CSS:

*:selected {
    background-color: @selected_bg_color;
}

.cell {
    background-color: @base_color;
}

They have the same CSS precedence, so then the last one applies.
The solution to this is place the pseudo-class rule about the
:selected state the last one. This is bad because it is very common
to have this precedence clash in CSS files of Gtk themes, and
because it is actually the case in the default Ubuntu theme (at
least in 13.04), called Ambiance.

This bug has been reported upstream (I have even provided a patch):
https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1211831

But in the meantime we can add this workaround in hyena, along with
a Hyena.Warning() to remind of the glitch.

Side note: This rendering glitch is also affecting the SourceView
treeview used in Banshee.ThickClient, and obviously this workaround
doesn't help there, so we will have to either find another temporary
workaround for that, or bug ubuntu-theme maintainers heavily.