[Gtk-sharp-list] Static class methods

[Mike Kestner]

I checked in a patch tonight that is the first step in exposing a huge
amount of currently unavailable api.  To be honest, I was surprised at
how much api was being ignored by the parser because the methods
couldn't be matched up with a struct or gobject type.

If you run the generator on cvs trunk, you will see a ton of warnings
about unexpected Class nodes since I haven't committed the generator
support for all this new api xml yet.  It's probably going to take a
while to work through all the duplication-by-manual-wrapping and so on.

This is just a first pass from a parser standpoint.  Initially, I'm
producing <Namespace>.Global classes to attach all the non-groupable
methods, but I'm also grouping any methods of the form:

<namespace_prefix>_classname_<rest_of_method_name> 

on static-only classes named "Classname" if there are two or more
methods matching the form.  This leads to issues like gtk_accel_map_*
and gtk_accel_groups_* methods all being grouped under a Gtk.Accel
class.  Unfortunately, there doesn't seem to be a good way to divine the
proper way to group things like this, because just looking for the
longest matching substring produces fragmented classes with what should
be part of method names in them (eg foo_bar_get_string and
foo_bar_get_bool become Foo.BarGet.*).

The next iteration is probably to move the parser onto a file format
that's a little more expressive than the current .sources format so that
it's easier to specify seed classes for this process.  I mention this so
the documentors are aware that some of these static classes may be
somewhat dynamic until all this is worked out.

The good news is that cool classes like Gdk.Drag and Gdk.Rgb and
Gtk.Paint, and lots of other good stuff should be autogenerating Real
Soon Now (TM).

-- 
Mike Kestner <mkestner@speakeasy.net>