Revert "ThickClient: workaround for invisible (instead of bold) text (bgo#732838)"

This reverts commit f3f9c3300d415f86b78c20ca22fef077ec221c44
because it was just a workaround, and we have found the proper
fix.
TrackInfoDisplay: proper fix for not bold but invisible text (bgo#732838)

OnStyleUpdated() was in charge of filling the color fields of
TrackInfoDisplay class with values, but it could happen that
these colors were retrieved before OnStyleUpdated() hadn't been
run yet even once, which resulted in a black color, but all
transparent (alpha=0). The way to fix it is make the colors be
properties that query the proper value on demand if the value
had not been set yet, or is resetted.

Thanks to Bertrand Lorentz for the heads up about the hint of
what was really going on badly.
TrackInfoDisplay: proper mid color for 'from' and 'by' (bgo#732898)

The mid-color between the default text color and the background color
of the widget was not being calculated properly because the background
color obtained for the TrackInfoDisplay widget was the same as the text
color. This behaviour must have changed recently in GTK3, but what we
are sure about is that using the Parent's reference colors we get the
proper colors again (probably because the parent of this widget would
be a ToolItem, inside a Toolbar, which has its background color surely
defined, compared to TrackInfoDisplay widget which is implemented in
the Banshee codebase.
TrackInfoDisplay: consistenly choose a color for both line layouts

The Pango.Layout objects 'first_line_layout' and 'second_line_layout'
were being assigned a colour in different ways, which could be a bit
confusing (the latter was using <span color="xyz"> markup, the former
was using Cairo.Context.SetSourceColor() API), so let's use markup
in both cases.

This commit changes behaviour, but doesn't (shouldn't) produce a
different rendering result in any way.