Naming and function binding strategy for 0.4.0

[spk121]

After playing with 0.3.x for a while, I disliked how it was difficult to look at official Gtk docs and then guess what guile-gi's binding should be. That's because 0.3.x tried to be good Scheme, when it really should be good Gtk. It should be possible to look at the official docs and immediately know what the Guile binding is.

Docs, after all, are the most important thing. Generally, no one reads offline docs, and , and I doubt any guile-gi maintainer (lol) wants to maintain a website of the guile-gi bindings of GObject libraries.

Some ideas:

Use GObject's naming of classes without namespaces. "Window" not "GtkWindow"

For functions and signals, make the C argument list and the Scheme argument list as close as possible. For example...

Keep array length parameters. 0.3.x removed array length parameter arguments because it computed array lengths from the arrays. Put them back in and use them, but let some symbol represent computing array length from the array (#f or -1 or ... or _)

Keep output parameters. 0.3.x did not use output parameters as procedure arguments because that is not normal in Scheme. Instead all output parameters were added as extra return values. For 0.4, put output parameters back in as function arguments. But add a syntax for the output argument to represent the user's choice to instead add them as extra return values ('#f' or ... or _).

If the user actually wants to use output arguments, s/he can pass in writable locations (make-variable variables, SRFI 111 boxes).

Don't require the predicate and mutability decorators '?' and '!'. It is good Scheme style, but, hard to guess from the official Gtk docs.

Use Gtk sigils. "::signal" for signal classes. ":parameter" for parameter accessors.