Improve Gtk bindings generator

[stackotter]

The Gtk bindings generator (see the GtkCodeGen target) is currently quite janky because I'm usually only touching its code when I'm adding a new view/feature to SwiftCrossUI that the bindings generator can't generate the required class bindings for. Most recent changes to GtkCodeGen have been bandaid fixes.

We'll eventually need the Gtk 3 and 4 bindings to become part of the public interface of the SwiftCrossUI package because we'll want to officially support creating custom platform-specific views. Before we make them explicitly public API we'll want the bindings to be pretty complete (and consistent).

This issue is very vague, so it's more of a tracking issue than anything. Here are some related subtasks that come to mind;

• [ ] Update generator to avoid unnecessary type name conversion edge cases (currently quite a few hardcoded conversions)
• [ ] Support interfaces properly
• [ ] Update the GObject class to support wrapping both owned and unowned references. Currently it assumes ownership and calls destroy/unref on deinit of the Swift class. This will make it possible to provide bindings for properties with non-primitive types.
• [ ] Support generating bindings for methods
• [ ] Provide a way to define custom widgets from Swift if possible (currently requires a bunch of C code)
• [ ] Provide a way to override virtual methods (currently also requires C)
• [ ] Get things to a point where we can generate bindings for all Gtk types (excluding a few if there are some impossible/problematic edge cases)
• [ ] Reduce the number of manually written widget bindings
• [ ] Only attach to signals for which the class has a non-nil closure. The current approach probably isn't very performant.

I'll update this list of tasks with new ones as I think of them.