MediaPanel: move the FIXME to the proper place

The FIXME introduced in previous commit is better placed in the addin.xml
file, to avoid running the extension point at all, to save some CPU cycles.
GStreamerSharp: remove superfluous state change events by PlayerEngine

While debugging GStreamerSharp backend, I noticed a sequence of events
which was much more different to the usual one when using the GStreamer
(unmanaged) backend. Instead of:

 Ready -> Idle -> Loading -> Loaded -> Playing

I was seeing:

 Ready -> Idle -> Loading -> Playing -> Loaded -> Playing

This was caused by useless events fired by the backend, which are not
fired by the unmanaged GStreamer backend in its corresponding Play()
and Pause() methods.

This also made the process of adjusting the video window to the frame
of NowPlaying source happen later, so it would cause an ugly effect on
slow machines.
GStreamerSharp: port to GTK3

Even though GStreamerSharp backend doesn't strictly depend on GTK at
compile time, it uses GDK at runtime to get the handle of a Window
in order to tell GStreamer where to render a video. To do this,
it uses a P/Invoke to an unmanaged library which was still pointing
to GTKv2.0 instead of GTKv3.0. This was causing the following errors:

(Nereid:16860): GLib-GObject-WARNING **: cannot register existing type `GdkWindow'

(Nereid:16860): Gdk-WARNING **: /build/buildd/gtk+2.0-2.24.17/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window

We leave a couple of FIXMEs for Windows/Mac platforms.

Signed-off-by: Andrés G. Aragoneses <knocte@gmail.com>
GStreamerSharp: make video playback work properly again

VideoManager initialization being commented out meant that video
playback was working, but not in the proper place (a new window
would pop-up instead of playing the video inside the NowPlaying
area). This was caused by the bad usage of the Gst# method
Gst.Bin.GetByInterface(), which receives a GType, but was getting
a Type of an interface that corresponds to the GInterface type.
The way to do it is using the -Adapter class that maps to this
GInterface.

We commented out other lines that cause the player to freeze/hang
altogether (probably related to some threading deadlock). Commenting
them out means that GStreamerSharp still has a bug with regards to
playing a second video while a first one is already being played,
but the latter bug should be easier to solve, for now, than the
freezes.
GStreamerSharp: convert some Monitor calls into a lock{} block

There was some synchronization-related Monitor.{Enter|Exit} calls here,
which can be translated to a lock(){} block, which is:

 - Better syntax, as it avoids the fact that you could forget the call
 to Monitor.Exit().
 - Better protection against exceptions, as the Monitor.Exit() call that
 is generated by the lock's syntactic sugar is inside a finally{} block.

The original author of this code probably thought that it was better to
use two Monitor.Exit() calls in order to exit the synchronized region as
soon as possible, but using a return statement inside a lock{} block for
bailing out early is also possible.
WIP for Gst#1.0