March maintenance

See merge request !929

Docs: Various markdown fixes

See merge request !930

The `## Some heading ##` form of heading, while valid, was only used
on _some_ headings in _some_ files. Standardize to `## Some heading`.

- Identifier has to be followed by a colon
  (`[1]: https://...` not `[1] https://...`)
- Title, when provided, must be enclosed in double-quotes

Now that we have TextEncoder and TextDecoder, not only the old ByteArray
object is legacy, but also the whole ByteArray module is legacy. So move
its tests into testLegacyByteArray and delete the testByteArray file.

These can all be replaced by TextEncoder/TextDecoder. In the case of
ByteArray.fromGBytes(), call .toArray() instead on the GBytes instance.

This is now just testing assignment to a Uint8Array, not a special
ByteArray object that is backed by a GByteArray. There's no need to test
this, since it's just part of JS.

I had previously thought that this was sufficient on macOS; if a library
isn't found in the default path, we fall back to the build directory.
However, this causes hard-to-track-down errors when running tests while
there is also an earlier version of GJS installed to the default library
path.

So, better to just have the same behaviour as on other Unix.

We don't want the IWYU job running on previous stable branches. The
stable branches were selected with a regex that was written in the
'gnome-3-38' days, so doesn't match the names of more recent stable
branches, like gnome-46. Fix the regex so it matches both.

g_type_interfaces() on an interface GType is always going to return an
empty list. Interfaces can have prerequisite interfaces (fetched by
g_type_interface_prerequisites()) but we should not enumerate their
properties in this function.

In all these places, we are creating a JSObject and almost immediately
storing it in a MutableHandleValue. If there's no operation that can
potentially GC in between creation and storage, then there's no need to
root the object.

https://hg.mozilla.org/mozilla-central/rev/254ebcb5c068379eb153add958bffc95d8d7a11e
https://hg.mozilla.org/mozilla-central/rev/8c0cf85100bda151fc311c939f0c7230700318b1
https://hg.mozilla.org/mozilla-central/rev/be67f9cc5dc8425851c47f7ed0654b908a07aa59

Use the new evalInFrame() function to improve the keys command to handle
exceptions raised while printing the expression's keys. Print the result
directly, rather than calling into the debuggee to print it.

Also handle the cases gracefully where the argument isn't an object, or
doesn't have any own properties.

Change 'keys' to 'own properties' in the description, in case the user is
looking up help for the keys command because they don't know what keys
are...

Usually if we are evaluating an expression inline for it to be used in a
command, we don't want an exception occurring from the evaluation to
interfere with the control flow of the program. We just want to print and
swallow the exception.

This adds a new function evalInFrame() which evaluates the given
expression inside the current frame, with debugger bindings. Refactor
throwOrReturn() to use this function.

Aside from dealing nicely with exceptions, this adds the feature of being
able to use debugger bindings with the return and throw commands, like
'return $3'. Add tests for these new features.

To use the throw or return commands, you have to be in the newest frame.
The error message would previously reference throwing, even when using the
return command. Fix the message and add tests.

The throw command should test throwing an expression, not a statement.

Consecutive conditions that check for JS errors can be collapsed.

Updates to the latest versions. eslint-plugin-jsdoc dropped the
newline-after-description rule in favour of the more comprehensive
tag-lines rule.

We never used GjsMaybeOwned<JS::Value> anymore, except in tests. There's
only GjsMaybeOwned<JSObject*>, so we don't have to have the extra
complication of a template parameter.

Oddly, there are some consts and constexprs that have to be removed even
though GCC accepted them when it was a template.

Surprisingly, depending on what types g(u)int64 and (u)int64_t are aliased
to, it may not work interchangeably. Since we are using the stdint.h types
we need to use the inttypes.h macros, as well.

doc: Document how to get a stack trace

See merge request !864

repo: Handle GioUnix/GioWin32 types being returned from Gio methods

Closes #610

See merge request !928

Add a CI check for config.h, and some other useful checks

Closes #447

See merge request !926

GBytes to be accepted by TextDecoder

See merge request !903

It may happen that a Gio method (such as Gio.Subprocess.get_stdout_pipe())
returns an object from GioUnix. We need to handle that case in four
places: gjs_lookup_object_prototype(), gjs_lookup_object_constructor(),
gjs_lookup_interface_constructor(), and gjs_value_from_g_value_internal().

Introduce a new method gjs_lookup_gtype() that calls
g_irepository_find_by_gtype() and then performs the necessary adjustments
afterwards.

Closes: #610

gi: check for if return type is a pointer in ffi_pointer conversion

Closes #605

See merge request !927

The tag can be VOID and we don't want to return a null pointer
in those cases. It manifests as failures on specific platforms,
particularly ppc64/ppc64le.

This is an unintended side effect of the refactoring done in
381a06ee.

Fixes #605

This adds a check to enforce the order that the headers are included in,
described here:
https://gitlab.gnome.org/GNOME/gjs/-/blob/master/doc/CPP_Style_Guide.md#header-inclusion-order

[skip iwyu] due to IWYU bug with <alloca.h> showing up in profiler.cpp.

The version of IWYU we are currently using has a bug where it tells you
to remove <alloca.h> if it's included, but add it if it's not there. Add
a way to just skip the job for one merge request.

doc: avoid reference to Gio.UnixInputStream

See merge request !925

Since this has been moved to a separate platform-specific library,
let's avoid referencing it in our documentation by using a
Gio.MemoryInputStream instead.

object: Only accept plain-object property bags in GObject constructors

Closes #580

See merge request !923

We have, for a long time, allowed these objects to be any objects.
However, this causes problems, because people do things like this:

  new Gio.FileIcon(myFile)

instead of

  new Gio.FileIcon({file: myFile})

whereas Gio.FileIcon doesn't support a null file property. Probably this
is a confusion with g_file_icon_new().

On the other hand, sometimes it probably just works. And maybe there are
cases where people are doing it intentionally.

We'll land this early in the GNOME 47 cycle and back it out if it really
causes problems with existing code.

Closes: #580

GObject: Throw on data stashing methods and refcounting methods

Closes #423

See merge request !922

boxed: Prevent name conflicts between boxed fields and methods

Closes #547

See merge request !921