seed-os.c: include util.h for openpty() on macOS

See merge request GNOME/seed!1

Basically a string fix. Although I think this should be fixed someway
else.

Seed.js content is visible from the main Javascript context.
That means that an object trying to use "GIRepository" as global var
will get an error.

Seed.js should hide GIRepository in an anonymous context to use it.

When the argument prediction took place, there's no need to
send the Array size as argument when passing arrays to GLib methods.

When a constructor raises an exception it needs to return NULL.
WebKitAPI excepts an JSObjectRef for object constructor, we can't
return a JSValueRef with a NULL value and expect that webkit will be OK
 with that.

Fixing this also fix some tests that were XFAIL-ing and
now passes.

When a constructor raises an exception it needs to return NULL.
WebKitAPI excepts an JSObjectRef for object constructor, we can't return
a JSValueRef with a NULL value and expect that webkit will be OK with
that.

Fixing this also fix some tests that were XFAIL-ing and now passes.

It was failing due to what I believe be a bug in GTK.
After calling widget_set_opacity(X), widget_get_opacity() won't
return X as the set_opacity rounds the value.

Looks like 'info' was removed a while back due to a crash.
However I couldn't reproduce this crash so I'm adding it back and
fixing the test

Looks like that, depending on the buildsystem, the argv value
might be FOO/lt-seed or FOO/seed. So we are fixing this test accordingly.

.. of the engine using mostly existing API.

https://bugzilla.gnome.org/show_bug.cgi?id=771520

Examples of builtins are "print" or "quit".

https://bugzilla.gnome.org/show_bug.cgi?id=771520

https://bugzilla.gnome.org/show_bug.cgi?id=771520

https://bugzilla.gnome.org/show_bug.cgi?id=771520

If `imports` is available, there's no reason to error out with
a cryptic message (`searchPath` is not an array), it's better to
just let the import attempt happen, with the user obtaining
an undefined object instead of an exception.

https://bugzilla.gnome.org/show_bug.cgi?id=771520

gtkdoc-mkhtml will output html.stamp in the parent folder, and
it never got cleaned afterwards.

Not sure why doc/modules does not use the gtk-doc makefile
fragment, but I'm not going for the best solution, simply the
one that does not break distcheck by leaving build artefacts in
random places.

https://bugzilla.gnome.org/show_bug.cgi?id=771510

https://bugzilla.gnome.org/show_bug.cgi?id=771510

And use git.mk instead

https://bugzilla.gnome.org/show_bug.cgi?id=771510

https://bugzilla.gnome.org/show_bug.cgi?id=771510

https://bugzilla.gnome.org/show_bug.cgi?id=771510

.. in that directory, there are other errors in other places.

https://bugzilla.gnome.org/show_bug.cgi?id=771510

Without this, make check stopped recursing up at the first
subdirectory failure, in our case in tests/javascript/gtypes,
leading to:

* The incorrect impression that the test suite consisted of
  only 12 tests.

* Making it impossible for make distcheck to pass.

* First-time users wasting time figuring out what in their
  environment was responsible for these failures, as one
  usually expects make check to pass.

See
https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html

https://bugzilla.gnome.org/show_bug.cgi?id=771510

According to ECMA 262 3th edition SPEC [1], _to_boolean should return:
FALSE when the argument is NULL OR Undefined.

This fix should cover that and get ride of some warnings/exceptions.

[1] http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf
* section 9

GJS syntax allows the creation of GVariant using a custom constructor.

Even if it works, the old approach to call _init() methods was
incorrect.

The current implementation doesn't require the execution of hardcoded
javascript anymore.