build: build: Re-enable disabled warnings during compilation

Those warnings were disabled a long time ago to work around bugs in old
mono compilers.

Also update to latest Hyena from git master, to bring in the equivalent
change in Hyena.
i18n: Update translators.xml
Nereid: Remove ugly black frame border around SourceView
ThickClient: workaround for invisible (instead of bold) text (bgo#732838)

After several hours attempting to find a reduced testcase for this
problem (which appears to be somewhere deeper in the stack: pango,
cairo, or gtk), I've found this harmless workaround that actually
makes the first line of text (in TrackInfoDisplay class) be more
consistent with the second line of text (the latter already wrapped
other markup elements with a wider <span> element using the default
text colour).

The TextColor and BackgroundColor properties seem to have wrong
values though (both black, rgb#000000), compared to the stable
branch (GTK2), but that will be tracked in a different bug, because
it is unrelated to this issue.
build: fix the build when using MonoDevelop instead of autotools

There were several errors of this type[1] which just required to
include missing references.

[1] Error CS0012: The type `Foo' is defined in an assembly that
is not referenced. Consider adding a reference to assembly
`Bar, Version=X.Y.Z.T, Culture=neutral, PublicKeyToken=null'
(CS0012) (Baz)
Fixup: fixed selecting option values (bgo#732993)

Instead of adding to a list new length of text, sum of previous and
current text was added. That causes widening range of next option values.
Because of that, it was impossible to select e.g. fifth (or further)
value.

Signed-off-by: Andrés G. Aragoneses <knocte@gmail.com>
Fixup: added an informative column (bgo#732339)

This column may be useful so other extensions that use the
MetadataFixer can give more info about the track being fixed
(current solvers of this extension can fix many tracks per
row, so this may not be useful for them, because using just
a cell to show information about more than one track may be
ugly; but the solvers being developed in b-c-e mostly add
one-fix-per-track solvers, therefore the HasTrackDetails
property will be marked as FALSE by default, but virtual,
so derived classes can override it).

Signed-off-by: Andrés G. Aragoneses <knocte@gmail.com>
Updated Polish translation
Updated Czech translation
Updated Brazilian Portuguese translation
Updated Basque language
Updated Basque language
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.
build: add .pc file for Banshee.NotificationArea extension

This is needed by the new SongKickGeoLocation extension in b-c-e.
Revert "build: add .pc file for Banshee.NotificationArea extension"

This reverts commit e8c7720c8ac66f3a9aec2e5c75d50989df70f12d, because
the reference was actually not needed, see:

https://gitorious.org/banshee-community-extensions/banshee-community-extensions/commit/3e5999099055b7fc01635071222a84c37c873276
GStreamerSharp: fix build with MonoDevelop (bgo#724752)

We had to use the <Package> element, not a HintPath. And also the
publicKeyToken was wrong...
GStreamerSharp: improve previous commit to fix the build (bgo#724752)

Previous commit [1] fixed the build for MonoDevelop in Linux, but
could likely break the build for Windows, where we don't use pkg-config
(we just place the dependencies in a directory). So seems like using
<HintPath> along with <Package> element doesn't generate any conflicts.

[1] https://git.gnome.org/browse/banshee/commit/?id=1ea5969f81f951009202e4884b01eda6ffd671f7