Use girepository to invoke library functions

The current generation code is unfortunately an unmaintainable mess. I had no idea when I started writing it how many parameter types and variations there were. Nor did I understand how many of the permutations would need to be handled. As a result I can't see a way to migrate the current code to a better place. I'd normally prefer to iteratively refactor code to improve it, but in this case I don't think that it's practical.

The generated code is also problematic in that it's very slow to build. This is mostly because of the extensive use of cgo. It's in every wrapping function, and there are many generated C functions for callbacks. This makes development of gobbi painful, with continuous rounds of code generation and slow builds.

It's difficult to move forward with the code as it is. Issues #16 and #17 are examples of cases where I struggle to work with the existing generation code.

I am looking at re-writing to use girepository for invocation of library functions.

Pros

the generated functions that wrap library functions will be become simpler, and will not contain any cgo code
the code that generates the wrapper functions will be simpler
all cgo code will be in one or two internal packages
- all of the complexity of the multitude of parameter types and variations will be in here
- all of the marshalling of parameters between Go types and C types will be in here
- all of code dealing with transfer of ownership will be in here
- much of the code will be amenable to unit testing
building will be much quicker

Cons

there will be a small overhead on function calls
unavailabilty of a library function (for example running an application on a system with older than required version of a library) will not be detected until it is first called

Initial work is proving promising. It will be at least several more weeks before it's in a reasonably useable state.

pekim / gobbi

Use girepository to invoke library functions #20