Switch to auto-generate code for more direct libostree api usage

[sjoerdsimons]

Hey,

So i've been playing a bit with ostree-go, getting it to implement just enough for my use-case (which is to build images really). Part of doing so made me understand the project a bit better, which led me to some questions.

One thing that was somewhat surprising to me is that it's not just (or at least has) a small wrapper around libostree directly to make the same API usable from Go but more modelled after the various ostree builtin commands, which is not unreasonable but when ostree is becoming libostree the former may make more sense :).

But that also made me wonder whether the option of autogenerating the bindings via go-gir-generator was evaluated? Writing them by hand tend to be somewhat cumbersome and error-prone (fwiw the current code leaks in quite a few places as it doesn't free C.CString results nor seems to handle gobject lifetimes). (I'm somewhat surprised that gogtk3 is seemingly handwritten as well..)

Would there be an interest in e.g. a gir-go-generator based libostree binding to rebase the potentially useful convenience layers on top or does that not fit within the scope of this project?

[ashcrow]

Some interesting generation utilities:

• https://github.com/linuxdeepin/go-gir-generator
• https://github.com/xlab/c-for-go

It would seem to me that generation plus some and clean up to pretty up bindings would be easier to maintain. @cgwalters WDYT?