Prefer GValue to GIArgument

[spk121]

Right now C values are stored in both GValue and GIArgument types, which is not ideal. The use of GIArgument types could be reduced: GValue instances could be general value storage solution for the C side. The use of GIArgument instances could be limited to immediately before and after using g_function_info_invoke.

There was a previous attempt at accomplishing this. The previous attempt was perhaps wrongheaded in its approach. That approach assumed that one of the the two necessary conversions (either from SCM to GValue or from GValue to GIArgument) could be done without reference to GigTypeMeta information. It tried solve that problem by inventing new GValue types so that the GValue to GIArgument conversion did not require GigTypeMeta information. But to pull it off, it had to invent several new GValue types, which was not ideal.

Conceding that GigTypeMeta is necessary for both SCM to GValue and GValue to GIArgument conversions, we could make GValue the standard storage of C values.

[spk121]

I talked to the g-golf maintainer, who himself has talked to the GObject Introspection about the duplication between GIArgument and GValue. Apparently they feel there is too much technical debt to do anything about it now, but, they would prefer GIArgument over GValue.

[LordYuuma]

IIRC the GValue vs. GIArgument discussion for our lib was sparked in #28, where I strongly voiced my preference to use GValues for both fields and properties. However, as a result of #43 we eventually removed field support in #64. However, we still have the problem, that our GValue code behaves differently from our GIArgument code. For instance, we can unpack lists through getters, but not through properties.

As a solution to this issue, I think we can use GParamSpecs, which we already use everywhere in our property handling code. We could store the GigTypeMeta as qdata and then refer to it. Doing that we'd only have to add GigTypeMeta as an optional argument to all our SCM to GValue conversions and adapt the conversion rules according to what we've already written. If we really wanted to express GIArgument conversion in terms of GValue, we could then use the various getters to extract the raw value into this union.

[LordYuuma]

Given #96, I think I do somewhat understand now, why GObject-Introspection is not based on GValues in this regard. If it were, it would not at all be possible to load a different version of GObject, whereas it seems somewhat possible with GIArguments. Which in a weird way means we're back to square one. I think we should be able to keep most of our GigTypeMeta and GigArgMap however.