Currently, the ScintillaObject signals can't be used from python code via
gobject-introspection. This is because g-ir-scanner does not properly scan
the signals.

For signals, there is the additional requirement that parameters have are
registered GTypes. For the sci-notify signal, this can be accomplished by
boxing SCNotification.

In addition, g-ir-scanner also runs on Scintilla.h where it picks up
additional structs.

test/gi/ is updated accordingly. The test python script is enhanced
to showcase the signals (some fixes to the makefile are included as well).

This makes it easier to update or add new marshallers.

Also, re-generate the current one using a current version of
glib-genmarshal, which generates different output (accessing different
fields for enum and flags) since at least 2008.  Although neither of
these types are currently used, it seems safer this way.

Currently, the ScintillaObject signals can't be used from python code via
gobject-introspection. This is because g-ir-scanner does not properly scan
the signals.

For signals, there is the additional requirement that parameters have are
registered GTypes. For the sci-notify signal, this can be accomplished by
boxing SCNotification.

In addition, g-ir-scanner also runs on Scintilla.h where it picks up
additional structs.

test/gi/ is updated accordingly. The test python script is enhanced
to showcase the signals (some fixes to the makefile are included as well).

The idle callback removal clause in the ScintillaGTK destructor got
broken in 4e5c321dda8e69104cb7b639c3107dc11dbc00f6, leading to the
callback not being removed thus possibly running after the instance
destruction.
Indeed, gdk_threads_add_idle() wraps g_idle_add() with a custom user
data, thus making the g_source_remove_by_user_data() call in the
destructor incorrect, as we give it our own user data, not GDK's
wrapper one.

Fix the callback removal not to use user data matching to avoid this.

matches g_iconv exactly. Make character set name buffer dynamically sized.