Fix leak when virtual function is unimplemented.

See merge request GNOME/gjs!498

cleanup: Don't use GSlice anywhere

See merge request GNOME/gjs!488

In case the function initialization fails for some reason, we only need
the info function to be set in case we have defined arguments, otherwise
we might have just failed at the early stages of the cache-init function
and nor the GI info or the arguments are set.

If we throw during the arguments cache creation as we fail during an early
stage of init_cached_function_data, we don't save the function GICallableInfo
or the already allocated parameters, but we'd just return loosing
track of allocated data.

This is not just a potential leak, but also wrong as if a method
introspection is malformed or not fully supported by gjs, we'd just
assert crashing badly during function unallocation because no function
info is set, instead of just throwing as expected.

As per this, let's save the function private informations (such as the
callable info and the arguments cache) as soon as we allocate them,
and update the number of initialized arguments in real time, so that
we can partially de-allocate the arguments cache in case of errors.
This also implies that during function de-init we must ensure that
we don't overflow using the marshallers pointer to check if we've ever
initialized such argument cache and to figure out how many we've allocated
other than of the total number of the introspected function arguments.

GSlice API is going to be deprecated [1] and marked as such for some
years now, even if this change didn't happen yet, there's no point to
keep GSlice usage in gjs, considering that we can semplificate it with
calls to system allocator using g_new/g_malloc and g_free.

Once I applied this change, I've noticed that the memory sanitzer found
some leaks in the trampoline code that for some reason GSlice was hiding
and that this commit underlines.

[1] https://gitlab.gnome.org/GNOME/glib/-/issues/1079

When creating the trampoline, if we have an early return, we need to
cleanup the allocated memory or we'd leak.

This happens for example during the GObjectClass test "gracefully bails out
when overriding an unsupported vfunc type", where the trampoline
creation fails, but in such case we never free the allocated memory

Everywhere else in gjs_callback_closure() that writes into result
does so by first converting the JavaScript object into a GIArgument
according to GIArgument conventions, and then copying the GIArgument
into result according to FFI conventions. In particular, for small
integers like enums and flags, the value copied into the GIArgument
is 32-bit, but the value pointed to by result is typically
pointer-sized, which is larger on 64-bit platforms.

However, the code path for vfuncs that fail at the JavaScript level, but
have to return *something* at the C level, was instead treating result as
being a pointer to a GIArgument. Writing a small integer to a GIArgument
only sets the first few bits (the first 32 for enums and flags),
leaving the next 32 bits of a pointer-sized quantity on a 64-bit
platform uninitialized. On little-endian CPUs, if the next 32 bits
happen to already be all-zeroes, the right thing would happen anyway,
but we can't count on that.

In particular, this resulted in the test-case
"Wrong virtual functions marshals an enum return value" in GIMarshalling
failing on big-endian LP64 architectures like s390x, after I fixed the
other code paths involving GArgument and enums/flags for s390x in
commit 1ba19d63 "function: Use GIArgument.v_int for enum and flags types".

This change requires initialization of ret_type_is_void to be moved
further up, so that it occurs before the first "goto out".

Resolves: https://gitlab.gnome.org/GNOME/gjs/-/issues/319
Signed-off-by: Simon McVittie <smcv@debian.org>

It is common for a base class to not implement a virtual
function and leave is as NULL, this currently causes GJS
to crash if subclasses chain up. This change makes it a
recoverable JS-level error.

Fixes #313