Better signal support

Rationale

Over the years with the current implementation of signals througout libglade years until today, signals in Glade files have never been useful in serious applications, mostly because you have no real control on the user data.

Proposal GtkBuilder side

To fix this I propose we add the "user-data-type" property to the "signal" tag definition in the GtkBuilder format, allowing for more types than the base "GObject" type; it should be easy enough to insert a generic GValue parsing routine, allocated strings and GBoxed values lifetimes could be attatched to the lifetime of the instance emitting the signal.

The GtkBuilder format also needs <signal> attribute "swapped" to indicated whether to swap the user data or not, this must unfortunately be TRUE by default for "user-data-type"s of GObject or derived (for backwards compatability reasons).

It would be particularly interesting to add api to GtkBuilder such as:

void gtk_builder_add_symbol (GtkBuilder  *builder, 
                             const gchar *symbol_name,
                             gpointer     symbol_location)

This could allow us to add another different attribute to the signal tag, <signal ...symbol="yes">, and allow the user to provide named symbols to be passed in as user data at load time.

Glade side

The Signal editor has forever needed a rewrite.

It will now need to offer control on the user-data-type, optionally enable user-data field based on if a type is selected, and also allow control on the "swapped" attribute.