Not sure if we should go this route or wrap in a callback, I'd prefer
if we can go this route to avoid adding JS wrapping

Various cleanups

See merge request GNOME/gjs!624

There's no point to use a custom implementation of a double-linked list
to hold the list of ObjectInstances we've around, however while this can
be a fast option for adding/removing objects it's way slower during
iterating at garbage collection, and vector is always faster in such
operations when it comes when handling pointers [1].

As plus:
    - we avoid wasting memory for all the "next" pointers (doubled size)
    - we can remove elements using the swap-and-pop idiom (avoids resizes)
    - we resize the array forcing it to shrink at garbage collection
    - being a static member, we only waste once the space for the size

[1] https://github.com/3v1n0/stl-containers-benchmarks

closure (and trampoline): Reimplement to be a C++ class with custom heap allocator

See merge request GNOME/gjs!625

We're currently keeping a list of trampolines in a static vector, this
is acceptable (at least for a single-context scenario), but trampolines are
bound to a specific context so better to move the handling in the context.

GjsMaybeOwned had a notification support that was used only by Closures
(other than tests), this was causing adding an extra pointer to all
the types using it (including Object) that was mostly unused.

So, move this into private context, re-implementing it using our own
notifier (instead of relying on GObject's that needs a specific order) and
use it in closures.

Also add an hook to handle gc events on private context that will be in
later changes to cleanup more things, but for now is used to shrink the
closures vector once we've done.

The callback trampoline is in fact a GClosure, but we were just composing
one. We can instead just inherit from it now, given that the
Gjs::Closure will allocate the needed memory via the closure allocator
and handle the references via native closure reference system (avoid to
duplicate that).

As per this, some less memory used as we save a pointer and the
reference counting.

The only bit we need to handle is the destruction as we need to be sure
to call the proper type destructor on closure finalization.
So, adding an utility function that ensures this happens for each type
and that we won't call the base destructor twice.

To create closures we used to create an internal closure structure that
for which we were handling construction and destruction manually.

C++ allows us to use some nicer features though, and we can take
advantage of them once we leave the role of allocating and deallocating
the memory to GClosure functions.

This can be nicely done overriding the new and delete operators that
will give us the size to allocate exactly as the closure creator
function expects to receive.

Add Internship Getting Started documentation

See merge request GNOME/gjs!645